[Dev] Java 6: When Jars Attack

[Brett Wooldridge]

In the process of adding a new build-time feature -- generating overridden equals(), hashCode(), and toString() methods in client generated SOAP bindings - we were required to update to the latest version of the JAX-WS Reference Implementation.

Everything was cool after this upgrade for Java 5, but the issue we've encountered in the past with Java 6 shipping a back-level version of JAX-WS (2.0) has reared it's head again.  In the past, this issue only surfaced at runtime.  OSGi's default classloading delegation would to load (back-level) classes from the JRE/JDK and SOAP would break.  For this reason we had to take control of the boot delegation configuration of OSGi to steer it to our newer version of JAX-WS (by preventing it from delegating those packages).

However, now the bindings generated by the newer version of JAX-WS are taking advantage of newer methods in the JAX-WS class library and the absence of these methods in the back-level Java 6 implementation is resulting in a build failure (for Java 6 developers).  Meaning we used to get away with compiling against the back-level JARs and running against the correct ones, but this is no longer possible.

When we first encountered this issue (as a runtime problem) back in the August, we shunned the proposed solution from Sun of copying two jars into the <jdk>/jre/lib/endorsed directory.  Rightly so.  We should not require our user's to modify their Java installation in order to run ZipTie.  And WE should not modify their Java installation for them.  Fortunately, we arrived at the boot delegation solution, and all was well.  We are not so lucky now with this build-time failure.

In order to fix the build-time failure there are one of two possible solutions (that I see):


 1.  Modify our build to always fork javac for compilation and supply to it a -Djava.endorsed.dirs parameter that points at our newer JAX-WS jars or,
 2.  Developers on Java 6 follow the original Sun recommendation of copying jaxb-apis.jar and jaxws-apis.jar into /<jdk>/jre/lib/endorsed

As much as I hate to say it, I am recommending option 2.  Feel free to disagree (hence this email), but first hear out my reasoning.  This is a build-time issue, and not a runtime issue.  So, while it is annoying (mostly on the level of just feeling dirty) to have to augment our JDK installations this is an issue that only affects developers working with the ZipTie codebase.  It has no effect on our end users, no effect on installation, no effect on packaging, etc.  And it only has to be done when a new Java 6 is installed (read every few months).

If you disagree, I can't blame you.  And I won't be upset at all of somebody fixes the build (which entails changing how our custom zdist Ant task calls javac) to solve the problem.  Doing so will probably add maybe 10-20 seconds to the build due to forking.  All I'm saying is, from my perspective there is a workaround and while it might make you want to take a shower it is nearly painless to perform.  I don't believe the time required to fix it and the additional time it would take every time you build justifies "solving" the problem in that way.  Longer build times is a pain that keeps on giving.

I blame Sun.

-Brett

P.s. You'll find jaxb-apis.jar and jaxws-apis.jar in org.ziptie.server.metro/lib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20071115/a7aabcaf/attachment.html