Removing Xerces dependency?

[wilx]

I am looking into removing all instances of Xerces and xml-apis from our product. It looks like one of the instances where it is not currently removable is as Antisamy's dependency. Would it be possible to rewrite the few uses of org.apache.xerces in Antisamy with generic Java APIs or something else?

[davewichers]

I'm sure its possible, and its probably a good idea. We just haven't made it a priority. If you have some experience doing such rewrites of XML parsers any chance you'd be willing to submit a pull request with these changes? As you said, there are only a few.

[davewichers]

@wilx - We just made some progress removing some of the use of Xerces and replacing parts with what comes with Neko HTMLUnit, which contains its own slimmed down/maintained fork of parts of Xerces. If you look in the pom, there is a comment describing a suggestion on how to replace the last bits of Xerces we use in AntiSamy with something newer/better maintained.

[wilx]

@davewichers I actually did experiment with it back in November. But I couldn't get it to do what Antisamy needs it to do. See https://github.com/nahsra/antisamy/compare/main...wilx:antisamy:transformer-experiment?expand=1

[rbri]

@davewichers @spassarop spend some time with claude to get a replacement for the the serializer that let us finally remove the xerces dependency. Got something and also a huge test suite (>100) tests.
This might be a starting point... what do you think?

[rbri]

btw the new serializer has only ~1000 lines of code, much simpler than the xerces monster

[kwwall]

If you're going to replace XercesImpl, perhaps we should consider replacing it from the SAX XML parsers that are part of JAXP instead. I've been mulling over the idea of doing the same for ESAPI as well (which, granted, has a much smaller Xerces footprint than AntiSamy). And at the same type officially ditch your support for the DOM XML parser. (That should be an easy change for us to make on ESAPI.)

I will discuss it with the ESAPI team, but I think we should at least consider it as a possibility.

[spassarop]

The most common issues with updating anything here tend to be output differences (backward compatibility) and dependencies+Java version. So if this change helps moving forward, and output-breaking changes are low... I welcome it.