XML Hell

If you programmed in or used Windows, you are all too familiar with "DLL Hell", where DLL's get over-written by newer (or older) incompatible versions. Writing applications as piles of DLL's made sense when resources (particularly disk drives) were expensive, but not so much any more. However, this blog entry isn't about DLL Hell. It's about a related phenomena in the Java world - XML Hell.

One of the saving graces when Java first arrived was the freedom once and for all from DLL Hell. Of course, DLL Hell was really just the creeping scourge of versioning, and it came to Java with a vengeance in the form of XML Hell. I've been fighting with this little problem for the last few days. XML parsers and XSLT engines are supposed to be backwards compatible...the operational words there are "supposed to be". I'm working on a project where everything works great under JDK 1.4.x but causes blue smoke whenever you try to build it under Java 5. Turns out the problem is the version of the XSLT processor that comes with Java 5. One of the vendors of a 3rd party library in the application relies on specific behavior in an older XSLT processor that accidentally takes advantage of a bug in the older processor. The bug is fixed in Java 5, and causes everything to blow up at build time. Sigh....

The only platform that has gotten this right is .NET when using Strong Names (which can be a little cumbersome, but the fundamental solution is a good one). That's one area that .NET has definitely leap-frogged Java: versioning libraries. I hope that Java someday addresses this problem.