JAR-JAR JINX

In the spirit of the newly released Star Wars movie, this tip is about
the attack of the clones. Fortunately, I'm not talking about the kind 
that
will hunt you down; still, these clones will cause you pain. I'm 
talking
about an issue (or set of issues) around the Apache Group's Xalan and
Xerces projects.

THE CLONES

The clones in our case are packages and classes. The problem is that 
XML
and Java seem to be in a constant state of change. As new XML features
are created in specifications, they must be implemented somewhere. 
Often,
these new features conflict with older specifications and
implementations. This, in itself, is not such a big deal. However, when 
you realize that
these conflicting implementations are packaged and deployed with the
same cloned filenames, you can see why there's a problem.

There are three cloned files that give developers and administrators
problems. They are xalan.jar, xerces.jar, and crimson.jar. There is 
nothing
in the filenames of these files to indicate which version each is.

MORE PROBLEMS

Not only is it a problem that these files can have conflicting
implementations, but there are JDK deployments that include versions as 
well. The
JDK 1.3 has a special directory called lib/ext that will automatically
put any jar files within that directory into the classpath. This 
directory
is used to ease the installation of extensions to the base Java 
packages.
Because extensions are designed to be a part of the JDK (or JRE), it
makes sense to incorporate them directly into the Java Virtual Machine 
(JVM)
rather than manually adding them to the classpath.

Parsing XML documents in Java has become so common that several JDK
deployments include the Xalan and Xerces jar files. More importantly, 
they
are included in the lib/ext directory of the deployments. Although a 
nice
idea, this is prone to cause problems.

IBM includes an old version of Xerces in the lib/ext of its JDK version
1.3. This version doesn't include support for JAXP 1.1 and is, 
therefore,
incompatible with the most current Xalan versions.

Sun Microsystems has a similar problem. Its JDK version 1.3 includes
JAXP support with Crimson. Unfortunately, the crimson.jar deployed with 
the
JDK uses an older JAXP version that is also incompatible with the most
recent Xalan versions.

APPROACHING A SOLUTION

That's just the tip of the iceberg. When you start to consider building
applications using third-party or commercial modules, it gets worse.
Imagine that you need to integrate two applications using Java. The API 
for
one application uses the old xerces.jar from IBM, the other application
uses the old crimson.jar from Sun, and your code needs the most recent
versions of Xerces and Xalan.

The ideal solution would be that all vendors would upgrade their
versions to be current and then redeploy the application or module. 
However,
this is unlikely to happen.

Another option is to examine and understand how each application uses
the classes within each jar file. If the right conditions are met, you 
can
arrange the jar files in the classpath so that they are loaded in a
specific order. You might also consider ways to load your applications 
into
different Java Virtual Machines so that you can easily manage different
classpaths for each application. This would allow you to use the 
correct jar
files for each application and manage them separately.

Brian Schaffner is a senior consultant for Fujitsu Consulting. He
provides architecture, design, and development support for Fujitsu's 
Telcom360
group.

----------------------------------------