[External] : Re: Potential Thread-Safety Bug in XMLEntityManager

[Stuart Marks]

Hi yes, thanks for mentioning this.

In the context of API specifications, "immutable" often means that from the point of 
view of the public API, the state of the object cannot be observed to mutate. And 
yes it usually implies thread safety. Of course that's possible to achieve if none 
of the object's fields are mutated, but it's possible for such an object to have 
mutable fields. (String and BigInteger are examples of this.)

Unfortunately the CatalogImpl object is mutated to hold temporary state that's used 
during the resolution process. This temporary state doesn't really belong in the 
object itself, so it seems likely that a fix would involve refactoring this 
temporary state out of the Catalog itself into an object owned by some resolver 
object (or similar).

We'll take another look at the docs here to see if other updates are necessary.

s'marks

On 10/22/25 11:26 AM, Elliot Barlas wrote:
> Thanks, Stuart.
>
> Regarding specification, I noticed that the javax.xml.catalog package summary[1] 
> indicates that "A Catalog object is immutable." Immutable typically indicates that 
> internal state cannot be changed and it implies thread-safety. It might be worth 
> clarifying the javadocs.
>
> [1] 
> https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/catalog/package-summary.html
>
> On Tue, Oct 21, 2025 at 8:51 PM Stuart Marks <stuart.marks at oracle.com> wrote:
>
>     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
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkM3nOhEn$>
>     >
>     > 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
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java*L279__;Iw!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkHxYgLPG$>
>     >
>     > XMLEntityManager entityManager = new XMLEntityManager();
>     > XMLResourceIdentifier resourceIdentifier = new XMLResourceIdentifierImpl(
>     >         "http://example.com/dtd/sample.dtd
>     <https://urldefense.com/v3/__http://example.com/dtd/sample.dtd__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkAFCYHAv$>",
>     >         "sample.dtd",
>     >         "http://example.com/base/
>     <https://urldefense.com/v3/__http://example.com/base/__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkDeCD3yJ$>",
>     >         "http://example.com/base/sample.dtd
>     <https://urldefense.com/v3/__http://example.com/base/sample.dtd__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkA6PDux_$>");
>     > entityManager.resolveEntity(resourceIdentifier);
>     >
>     > Prior to the commit above, this code did not access a shared JDK CatalogImpl.
>     >
>     > -Elliot Barlas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251030/34acf18e/attachment-0001.htm>