Potential Thread-Safety Bug in XMLEntityManager

[Stuart Marks]

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