madbean

In the last couple of weeks, I’ve been pinged a few times by cow orkers in the FishEye development team who were complaining about a mysterious JDK1.5 dependency in our code. Their development builds were breaking on a JDK1.4 JVM with an error like:

java.lang.NoSuchMethodError: java.lang.StringBuffer.append(Ljava/lang/CharSequence;)Ljava/lang/StringBuffer;

The sweat started pouring the first time I got that complaint; FishEye requires 1.4, we compile with -target 1.4 -source 1.4, and that method doesn’t exist in 1.4, it was added in 1.5.

Have production builds been going out like this?!

I knew the answer to that question was “no”, because we have a check like this in our Ant build (this uses some ant-contrib tasks):

<target name="check-prod-build">
    <propertyregex property="build.jdk.version" input="${java.version}" regexp="^(1\.\d).*" select="\1"/>
    <if><not><equals arg1="1.4" arg2="${build.jdk.version}"/></not>
        <then>
            <fail>Build aborting
====================================
A PROD BUILD REQUIRES JDK1.4.x ONLY!
====================================
You are using ${build.jdk.version} (${java.version}).
            </fail>
        </then>
    </if>

</target></pre>

Then the reason for putting that check in came back to me: because -target 1.4 -source 1.4 can still produce class files that won’t run under 1.4. How? Because neither of those options change what rt.jar you are linking against.

This is best illustrated with a little example. Take this simple file:

public class Test {
    public static void main(String[] args) {
    StringBuffer b = new StringBuffer(”Hello, “);
    CharSequence s = “world!”;
    b.append(s);
    }
}

When compiled with JDK1.4 it will run under both JDK1.4 and JDK1.5, but not when compiled under JDK1.5:

$ export JDK14_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.4/Home
$ export JDK15_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home
$ $JDK14_HOME/bin/javac -target 1.4 -source 1.4 Test.java 
$ $JDK14_HOME/bin/java -cp . Test
$ $JDK15_HOME/bin/javac -target 1.4 -source 1.4 Test.java 
$ $JDK15_HOME/bin/java -cp . Test
$ $JDK14_HOME/bin/java -cp . Test
Exception in thread "main" java.lang.NoSuchMethodError: java.lang.StringBuffer.append(Ljava/lang/CharSequence;)Ljava/lang/StringBuffer;
        at Test.main(Test.java:5)

The culprit is the call to append(). In JDK1.4, the only call that matches is append(Object) and you end up with bytecode like:

invokevirtual   #6; //Method java/lang/StringBuffer.append:(Ljava/lang/Object;)Ljava/lang/StringBuffer;

But with JDK1.5’s rt.jar it matches append(CharSequence):

invokevirtual   #6; //Method java/lang/StringBuffer.append:(Ljava/lang/CharSequence;)Ljava/lang/StringBuffer;

Our Test.java is source-compatible with 1.4, the resulting Test.class as the correct class version for 1.4, but it is not link-compatible with 1.4 when compiled from 1.5. Have we learnt out lesson yet? Don’t be fooled by javac -target 1.4 -source 1.4: it can still produce class files that won’t run under 1.4.

Update Via Michael S and Chris N, you can also use the [code]-bootclasspath[/code], as described in the javac documentation.