Missing JAXP 1.5 support in Xerces - possible workarounds?

Question

I have run into some problems with the Xerces library, which is used by a third party lib that I rely on.

Xerces does not support JAXP 1.5, yet, which is contained in recent releases of JDK 1.7 and JDK 8. This leads to some problems, if Xerces is used as the XML parser, which can happen when several XML parsers are known to the system. Removing xercesImpl-v2.9.0.jar immediately fixes the problem, but then the 3rd party library isn't working anymore.

I can see two solutions to the problem:

1. It seems that the only bit from the Xerces library that is actually used is the org.apache.xerces.util.XMLCatalogResolver, used in CustomResolver.java. Are there other options for the catalog resolver instead of the Xerces one?

2. Another option seems to be to explicitly set the system properties for XML parsing at JVM launch. That way the JVM can told which XML parser to use and it wouldn't select Xerces anymore.

I found the following three properties:

 -Djavax.xml.transform.TransformerFactory
 -Djavax.xml.parsers.SAXParserFactory
 -Djavax.xml.parsers.DocumentBuilderFactory

This leads to two questions, though:

• Are these three properties the only system properties that need to be set in order to redirect the JVM to a specific XML parser?
• Could setting the properties explicitly have any side effects?

Answer 1

• Indeed, setting those three system properties would allow you to set the JAXP implementation to use at runtime.

• This will not help you if you use a 3rd-party library that has explicit dependency on Xerces, which seems to be the case for you (as you wrote, removing xerces from the Classpath causes one of your 3rd-party libraries to break).

So, first, decide whether you can avoid using that 3rd-party library, and use a replacement library that doesn't have a hard dependency on Xerces. As JAXP is quite mature now, the only reasonable scenario for a hard dependency on Xerces is if your 3rd-party library uses some very specific Xerces functionality for the purpose of its job.

If you can avoid using that 3rd-party library, then do so.

Otherwise, you can set these three system properties, and keep Xerces in the classpath. What will happen then is:

• Code that uses the JAXP API only, will switch to use your JAXP implementation of choice.
• Your problematic 3rd-party library will continue using Xerces.

There still is a chance that you'll run into problems, if there are classloading-related conflicts between Xerces and your new parser. In that case, you're pretty much out of luck, I'm afraid (unless you can somehow ensure that the two usages of the two parsers are done under different classloaders).