On Fri, 26 Jun 2026 05:54:20 GMT, Shruthi Acharya <[email protected]> wrote:
> When XSLT output method is html, characters supported by the target encoding > were serialized as HTML entity references (for example, é as eacute;). This > caused failures when the generated output was later processed as XML. > > **Solution:** > Update HTML serializer to write characters directly when they are supported > by the configured encoding, and retain existing entity escaping behavior for > unsupported characters. > > **Testing:** > Verified XSLT transformation with accented characters and confirmed generated > output can be parsed successfully without XML parsing failures. > > Performed Tier1 and Tier2 tests in Linux with and without the fix. No > regression found > > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8387291 > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I don't think `accumDefaultEntity` is the right place to be making this change. The only place it is called within `ToStream.java` is from `accumDefaultEscape` where the decision has been made to escape the character. It is also a protected method that can be overridden or called from subclasses, and I guess the reason the fix works is that `writeAttrString` in `ToHTMLStream.java` calls this method. This is code originally imported to OpenJDK from Xalan-Java upstream. Have you checked whether this bug exists there? It seems that although we have Xalan updates to OpenJDK like [JDK-8305814](https://bugs.openjdk.org/browse/JDK-8305814), they haven't updated the serializer code, which seems like it has now diverged quite a bit. I found [a twenty year old change](https://github.com/apache/xalan-java/commit/666e9b9df6f9f4bef281d4547d088bfa67009bad#diff-315ec5a1a41f86fa47ac6e1c53eb71ee0ee293c2dc2ca00acdafe8b4799a43f5) upstream which I think may fix this issue. It adds the same encoding check to `outputCharacters`, which is where the determination is made if the character is "dirty" and needs processing, like escaping. The bug is [XALANJ-2271](https://issues.apache.org/jira/browse/XALANJ-2271) and you likely at least want the follow-up for high surrogate characters, [XALANJ-2419](https://issues.apache.org/jira/browse/XALANJ-2419) I would suggest testing the upstream version and replacing this change with the upstream fix if that works. I also agree with Galder that the test case from the bug really needs to be converted to jtreg and included in the final change. Incidentally, there are no XML tests in tier1 and tier2 only has `javax/xml/crypto` and `com/sun/org/apache/xml/internal/security` via `jdk_security2`. You likely want `jtreg:javax/xml/jaxp` too. ------------- Changes requested by andrew (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/31689#pullrequestreview-4647371339 PR Comment: https://git.openjdk.org/jdk/pull/31689#issuecomment-4906451636
