Stefan Bodewig's Weblog

Fri, 29. Oct 2004

Apache Gump is the ASF's large scale integration project which currently builds a whole bunch of Open Source Java projects from source over and over again.

Apart from its regular runs performed on JDK 1.4 we also have experimental runs on Kaffe (more on that sometime later) and JDK 1.5. The results can be seen here. In short, they are a desaster since almost no project builds without special tweaks to either code or the build files.

Here are the most common traps:

Backwards incompatible API changes

Our all time favorite, isn't it? This time it is not JDBC but JAXP that is causing the biggest problems. org.w3c.dom.Node and javax.xml.parsers.DocumentBuilderFactory have changed, for example.

We had to drop Xerces-J 1 and Crimson from our Gump portfolio since nobody is going to adapt them. But not only parsers are affected, it will be interesting to see how things like Cocoon or dom4j will work out, once we manage to build the projects they depend on.

This means neither Xerces-J 1.x nor Crimson can be compiled or used with JDK 1.5. Sometimes software does go bad.
Source file encoding

I'm not sure whether this is a bug in javac or the default has changed silently or what has happened. javac will now choke on non-ASCII characters even if the source files use the platform's default encoding. This causes problems with @author tags of international contributors and similar comment contents.

The solution is to either use unicode escape sequences or explicitly specify the encoding attribute of your <javac> task (you can't rely on the defaults any longer).
New default for -target

Actually it already changed with JDK 1.4. Prior to JDK 1.4 it defaulted to 1.1 while JDK 1.4 changed it to 1.2. So generated classes became incompatible with JDK 1.1 and many project started to explicity specify target="1.1" in their build files. Others didn't since they didn't plan to support JDK 1.1 anyway. With JDK 1.5 the new default is 1.5, this means generated code can only run on JDK 1.5, which most likely is not what you want.

The solution for cross-JDK build compatibility is to explicitly specify the target attribute.
New default for -source

In JDK 1.4 the default was 1.3, in JDK 1.5 it is 1.5.

This leads to a few kinds of problems:
1. Your Enumeration enum = ... is no longer going to compile.
2. Combined with the new default value for -target, if you have specified -target 1.1 but no -source you will now get
```
javac: target release 1.1 conflicts with default source release 1.5
```
The solution for cross-JDK build compatibility is to explicitly specify the source attribute. To add to the pain, JDK 1.4.0 and 1.4.1 will not accept 1.1 or 1.2 as values for the source attribute.
No Xalan-J in the JDK

Ant's <junitreport> went through this and it took us until Ant 1.6.2 to finally make it work.

JDK 1.5 comes with Xalan XSLTC instead of Xalan-J 2.x as processor. This has a few consequences:
1. If you rely on Xalan extensions in your stylesheets they may no longer work. Some of them can still be used with XSLTC but if you used the "old" namespaces identifiers like "org.apache.xalan.lib.Redirect" you'll have to switch. See the XSLTC site for help and details.
2. If you have Apache's xml-apis.jar on your bootclasspath or use it via the "endorsed standards override mechanism", you'll probably have to put Xalan-J there as well since this jar defaults to Xalan-J as its TraX processor - which is no longer there.
3. XSLTC is an incredible memory hog. You'll probably want to use the endorsed standards override mechanism and use Xalan-J 2.6 (or Saxon) anyway.

path: /en/Apache/Gump | #