Hi Elliot,
Yes, this is indeed a bug. It seems that most of the XML and JAXP APIs aren't
thread-safe and so must be used in a thread-confined manner. (Hm, I can't seem to
find anything in the specifications about this... another thing to look at.) Most
JAXP objects are constructed on demand. However, as you point out they end up using
a shared CatalogImpl instance that represents the built-in JDK catalog. Since
catalog resolution mutates this object, it's a thread-safety issue.
I've filed
https://bugs.openjdk.org/browse/JDK-8370379
to cover this issue. Thanks for reporting it!
s'marks
On 10/14/25 3:07 PM, Elliot Barlas wrote:
Hello core-libs-dev!
There appears to be a thread-safety bug in
com.sun.org.apache.xerces.internal.impl.XMLEntityManager related to the
introduction of the following field[1] in the following commit[2].
[1] CatalogResolver fDefCR // the default JDK Catalog Resolver
[2]
https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5
Multiple threads executing the following sample code use the same underlying
javax.xml.catalog.CatalogImpl obtained from
JdkXmlConfig.getInstance().getJdkCatalog(). CatalogImpl is not thread safe. The
resolveEntity method mutates the underlying JDK catalog[3].
[3]
https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java#L279
XMLEntityManager entityManager = new XMLEntityManager();
XMLResourceIdentifier resourceIdentifier = new XMLResourceIdentifierImpl(
"http://example.com/dtd/sample.dtd";,
"sample.dtd",
"http://example.com/base/";,
"http://example.com/base/sample.dtd";);
entityManager.resolveEntity(resourceIdentifier);
Prior to the commit above, this code did not access a shared JDK CatalogImpl.
-Elliot Barlas
