[942118 views]

[]

[toggle ads]

Odi's astoundingly incomplete notes

New entries | Code

Do not use Xerces, Xalan any more!

For years Java developers were used to require Apache Xerces and Xalan for their XML stuff. But those times are over. All this stuff is no longer necessary in modern JDKs (since at least 1.6 basically) and it does more harm than good to have these jars in your classpath or endorsed libs!

The problem is that the Internet is littered with references to Xerces and that even their Website is totally misleading. If you read that stuff you would believe that this is actually usefull code. But it isn't any more!

The first sentence on the website is "Welcome to the future!". But that's from at least 2010! The classes in xml-apis.jar are from 2009! All the code is build for JDK 1.3! Come on! Anybody who is still running 1.3 already has a lot of problems with the memory model / thread synchronization, let alone security issues! xml-apis contains ancient versions of JDK standard classes. For instance XMLStreamException doesn't even initialize the Exception's cause field, getting you nothing but incomplete stack traces.

I really wonder why this project can't get around to admit that it is effectively dead. They should really put a big fat warning on their website:

DO NOT USE THIS CODE ON MODERN JDKs. THIS IS FOR ANCIENT OR EXOTIC PLATFORMS ONLY,  BASICALLY UNMAINTANED AND SUBJECT TO BITROT.

But no! All that 20 year old documentation still tells people to put that crap into the endorsed folder of the JDK where it will turn a perfectly good XML infrastructure into a jurassic version of itself.

These people don't realize how much worldwide developer time they are wasting by keeping this outdated website up!

Please also note that Xerces has security issues when exposed unconfigured to the Internet (webservices!), whereas JDK's built-in JAXP has sane defaults.

If your project still has Xerces, you should migrate away from it now. Chances are that you hard-coded some stuff on top of Xerces (like validation, feature strings, parser options, etc.). Use the modern JAXP equivalents!
posted on 2015-03-09 11:55 CET in Code | 5 comments | permalink
The "welcome to the future" statement at https://xerces.apache.org/xerces2-j/ is surprising indeed. It might make sense to contact those projects directly with your suggestions, if you haven't done that yet.
Already done: https://issues.apache.org/jira/browse/XERCESJ-1657

Guess what: nobody has ever answered.

This project is completely abandoned. Everybody has run away.
Sometimes I feel the same way about all these logging libraries out there, such as log4j, logback, slf4j.

JUL is already an extensible framework, instead of providing appenders and handlers, people started to create whole new frameworks. log4j should just have been allowed to die in the same way.

People tout the advantages of these frameworks in terms of isolated advantages (performance, asynchronicity, audit, etc, etc) , without ever mentioning they could have done the same by providing extensions under JUL.

And then there is the matter of none of them ever bothering unifying the configuration aspect, so even if you manage to put in a facade such as SLF4J, then it is still hell to unify the logging from different libraries using different frameworks.
I guess that what you are writing is only valid if one doesn't get hit by any of the (rare, but serious) bugs still present in the JDK-version of Xerces.

Example: https://stackoverflow.com/a/48843482

It is really sad, that we still have to bring Apache Xerces in as a dependency and JDK hasn't updated their code in so many years!

On the other hand: great that it is so easy to bring one's version. One line of Gradle did the job for me!
Can you believe it! After 8 years of playing dead man they managed to release 2.12.0. Clearly some people are still wasting their time beating a dead horse.