<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hi yes, thanks for mentioning this.</p>
    <p>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.)</p>
    <p>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).</p>
    <p>We'll take another look at the docs here to see if other updates
      are necessary.</p>
    <p>s'marks<br>
    </p>
    <div class="moz-cite-prefix">On 10/22/25 11:26 AM, Elliot Barlas
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAH=XN_qPTf16Tj_4tWEs3Hv8_ifzh2dnQMJe5Vn4c=Pk5xyiTQ@mail.gmail.com">
      
      <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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkM3nOhEn$" rel="noreferrer" target="_blank" moz-do-not-send="true">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://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$" rel="noreferrer" target="_blank" moz-do-not-send="true">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="https://urldefense.com/v3/__http://example.com/dtd/sample.dtd__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkAFCYHAv$" rel="noreferrer" target="_blank" moz-do-not-send="true">http://example.com/dtd/sample.dtd</a>",<br>
          >         "sample.dtd",<br>
          >         "<a href="https://urldefense.com/v3/__http://example.com/base/__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkDeCD3yJ$" rel="noreferrer" target="_blank" moz-do-not-send="true">http://example.com/base/</a>",<br>
          >         "<a href="https://urldefense.com/v3/__http://example.com/base/sample.dtd__;!!ACWV5N9M2RV99hQ!PKgSj2SeuOr4MCd4_Gx6yYDTmkSwn_53v3toPNh3ULqgJTW8B-suL5Rj6p6AR4cKJLpmLTdheaA8UfTNna9xkA6PDux_$" rel="noreferrer" target="_blank" moz-do-not-send="true">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>
    </blockquote>
  </body>
</html>