Question

Suppose I want to write an application that is targeting some JRE version (e.g. 1.6), but on the machine that I use to develop it, there is a newer version of the JRE installed (e.g. 1.7).

The naive approach is to set the compiler level to 1.6 (I use Eclipse, but that’s probably not very important, since the problem is general). However, that is not sufficient. Setting the source level for the compiler ensures that the source files use only the language features available for that Java version and therefore the generated class files have the right minor version, so the target JVM will be able to load and run them.

But there is another and more subtle problem: If I use a class or a method in my code which was added in 1.7 and try to run the app on the machine with 1.6 runtime installed, it fails with a NoClassDefFoundError or a NoSuchMethodError.

The problem is that the same program runs fine on the dev machine, because the 1.7 JDK installed on it does contain these classes. The compiler or the IDE do not complain either. The only indicators that I’m referencing classes and methods that won’t be available are the Since 1.7 comments in JavaDoc.

So how to ensure that I never use classes or methods that won’t be available in an older version of the JRE? Is the only reliable solution to always have the exact target JRE version on the build path? That would mean that I would need to install an extra JDK on my dev machine for every such case (1.7, 1.6, possibly 1.5, maybe even 1.4).

Answer 1

Use the bootcpasspath option pointing to a 1.6 JRE (specifically the rt.jar) during compilation. Doing so will force a check that all referenced classes, methods and attributes are actually present in the supplied rt.jar.

See the javac – cross-compilation options for more details.