<div dir="ltr"><div class="gmail-gs" style="margin:0px;min-width:0px;padding:0px 0px 20px;width:auto;font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div class="gmail-"><div id="gmail-:13q" class="gmail-ii gmail-gt gmail-adO" style="direction:ltr;margin:8px 0px 0px;padding:0px;font-size:0.875rem;overflow-x:hidden"><div id="gmail-:13p" class="gmail-a3s gmail-aiL" style="direction:ltr;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif;overflow:auto hidden"><div dir="ltr">Thanks, Stuart.<div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/catalog/package-summary.html" target="_blank">https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/catalog/package-summary.html</a></div></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Oct 21, 2025 at 8:51 PM Stuart Marks <<a href="mailto:stuart.marks@oracle.com">stuart.marks@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Elliot,<br>
<br>
Yes, this is indeed a bug. It seems that most of the XML and JAXP APIs aren't <br>
thread-safe and so must be used in a thread-confined manner. (Hm, I can't seem to <br>
find anything in the specifications about this... another thing to look at.) Most <br>
JAXP objects are constructed on demand. However, as you point out they end up using <br>
a shared CatalogImpl instance that represents the built-in JDK catalog. Since <br>
catalog resolution mutates this object, it's a thread-safety issue.<br>
<br>
I've filed<br>
<br>
<a href="https://bugs.openjdk.org/browse/JDK-8370379" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8370379</a><br>
<br>
to cover this issue. Thanks for reporting it!<br>
<br>
s'marks<br>
<br>
On 10/14/25 3:07 PM, Elliot Barlas wrote:<br>
> Hello core-libs-dev!<br>
><br>
> There appears to be a thread-safety bug in <br>
> com.sun.org.apache.xerces.internal.impl.XMLEntityManager related to the <br>
> introduction of the following field[1] in the following commit[2].<br>
><br>
> [1] CatalogResolver fDefCR // the default JDK Catalog Resolver<br>
><br>
> [2] <a href="https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5</a><br>
><br>
> Multiple threads executing the following sample code use the same underlying <br>
> javax.xml.catalog.CatalogImpl obtained from <br>
> JdkXmlConfig.getInstance().getJdkCatalog(). CatalogImpl is not thread safe. The <br>
> resolveEntity method mutates the underlying JDK catalog[3].<br>
><br>
> [3] <br>
> <a href="https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java#L279" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java#L279</a><br>
><br>
> XMLEntityManager entityManager = new XMLEntityManager();<br>
> XMLResourceIdentifier resourceIdentifier = new XMLResourceIdentifierImpl(<br>
>         "<a href="http://example.com/dtd/sample.dtd" rel="noreferrer" target="_blank">http://example.com/dtd/sample.dtd</a>",<br>
>         "sample.dtd",<br>
>         "<a href="http://example.com/base/" rel="noreferrer" target="_blank">http://example.com/base/</a>",<br>
>         "<a href="http://example.com/base/sample.dtd" rel="noreferrer" target="_blank">http://example.com/base/sample.dtd</a>");<br>
> entityManager.resolveEntity(resourceIdentifier);<br>
><br>
> Prior to the commit above, this code did not access a shared JDK CatalogImpl.<br>
><br>
> -Elliot Barlas<br>
</blockquote></div>