Consequences of running a Java Class file on different JREs?

Question

What are the consequences of running a Java class file compiled in JDK 1.4.2 on JRE 1.6 or 1.5?

Answer 1

Theoretically, nothing. The JVM is supposedly backwards compatible. Myself, I've never had a problem in that direction.

Answer 2

Depends entirely on what parts of the java library you are using. It could be anything from 'absolutely fine, no difference whatsoever' to 'OMG!! WHY HAS IT JUST FORMATTED MY HARD DRIVE??' (Well, perhaps not this second one, but it serves to support the point of it going from nothing to possibly bad :)).

Your class could also pick up on bug fixes in the library as well, which would mean niggling bugs disappear (or could be introduced depending on if you were relying on buggy behaviour or not).

AFAIK though, the java bytecode is backwards compatible so you shouldn't get any issues with it just not doing anything.

Answer 3

It should work. I don't remember encountering any problems with it, except when parts of the Java API are deprecated, in which case it'll explain what they are anyway and you can hopefully write a workaround. Of course, running a class file compiled with JDK 1.6 in JRE 1.5 would cause a problem - even a JRE only minor build revisions older will throw an error.

Answer 4

One positive consequence is that the 1.4 classes will still take advantage of speed improvements made to the JVM (although not necesarily improvements made to library classes).

Answer 5

just ran into a problem like this myself. I was writing code that should work with 1.6 but the college had 1.3 installed. Lots of methods just don't work i.e

input = ""+ JOptionPane.showInputDialog(null,"Enter a four digit number to " + (b?"encrypt":"decrypt")+".",(b?"4086":"5317"));

wouldn't work but

input = ""+ JOptionPane.showInputDialog(null,"Enter a four digit number to " + (b?"encrypt":"decrypt")+".");

would. the inputdialog method that accepts three agruments doesn't seam to exist in 1.3.

this is just a long winded way of saying working with 1.6 api on 1.3 results in head slamming incidents.

Answer 6

Java classes are forward compatible , e.g. classes generated using 1.5 compiler will be loaded and executed successfully without any problems on JRE 1.6. Generally your classes genereated by today java compilers will be compatible with future JREs (for example Java7)

The inverse does not hold : you can not run classes generated by 1.6 on older JREs (1.3, 1.4, etc).

Answer 7

Java compilers specify source and target compliance levels. This way, you can compile for any JRE from any other higher-versioned JRE. You need to make sure to use these compliance levels because there are API differences between JREs. For example, JRE 1.5 introduced StringBuilder at the compiler level. This means any time you do:

String s = "string1" + "string2";

The compiler changes it to:

String s = new StringBuilder("string1").append("string2").toString();

Obviously, this will break with a NoClassDefFoundError when you attempt to construct the StringBuilder.

Answer 8

The Java SE 6 Compatibility page lists the compatibility of Jave SE 6 to Java SE 5.0. Furthermore, there is a link to Incompatibilities in J2SE 5.0 (since 1.4.2) as well. By looking at the two documents, it should be possible to find out whether there are any incomapatibilities of programs written under JDK 1.4.2 and Java SE 6.

In terms of the binary compatibility of the Java class files, the Java SE 6 Compatibility page has the following to say:

Java SE 6 is upwards binary-compatible with J2SE 5.0 except for the incompatibilities listed below. Except for the noted incompatibilities, class files built with version 5.0 compilers will run correctly in JDK 6.

So, in general, as workmad3 noted, Java class files compiled on a older JDK will still be compatible with the newest version. Furthermore, as noted by Desty, any changes to the API are generally deprecated rather than removed.

From the Source Compatibilities section:

Deprecated APIs are interfaces that are supported only for backwards compatibility. The javac compiler generates a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated APIs, although there are no current plans to remove such APIs entirely from the system with the exception of JVMDI and JVMPI.

There is a long listing of performance improvements in the Java SE 6 Performance White Paper.