Java Writing JDK Release-Dependent Code

Java Writing JDK Release-Dependent Code

Problem

You need to write code that depends on the JDK release.

Solution 

Don’t do this.

Explained

Although Java is meant to be portable, Java runtimes have some significant variations. Sometimes you need to work around a feature that may be missing in older runtimes, but you want to use it if it’s present. So one of the first things you want to know is how to find out the JDK release corresponding to the Java runtime. This is easily obtained with System.getProperty( ):

System.out.println(System.getProperty("java.specification.version"));

Accordingly, you may want to test for the presence or absence of particular classes. One way to do this is with Class.forName("class"), which throws an exception if the class cannot be loaded—a good indication that it’s not present in the runtime’s library. Here is code for this, from an application wanting to find out whether the JDK 1.1 or later components are available. It relies on the fact that the class java. lang.reflect.Constructor was added in 1.1 but was not present in 1.0. (The Javadoc for the standard classes reports the version that a given class was added to the Java standard, under the heading “Since.” If there is no such heading, it normally means that the class has been present since the beginning—i.e., JDK 1.0.)

/** Test for JDK >= 1.1 */
public class TestJDK11 {
 public static void main(String[] a) {
 // Check for JDK >= 1.1
 try {
 Class.forName("java.lang.reflect.Constructor");
 } catch (ClassNotFoundException e) {
 String failure =
 "Sorry, but this version of MyApp needs \n" +
 "a Java Runtime based on Java JDK 1.1 or later";
 System.err.println(failure);
 throw new IllegalArgumentException(failure);
 }
 System.out.println("Happy to report that this is JDK1.1");
 // rest of program would go here...
 return;
 }
}

To check if the runtime includes the Swing components with their final names,* you could use:

Class.forName("javax.swing.JButton");

It’s important to distinguish between testing this at compile time and at runtime. In both cases, this code must be compiled on a system that includes the classes you are testing for—JDK 1.1 and Swing, respectively. These tests are only attempts to help the poor backwater Java runtime user trying to run your up-to-date application. The goal is to provide this user with a message more meaningful than the simple “class not found” error that the runtime gives. It’s also important to note that this test becomes unreachable if you write it inside any code that depends on the code you are testing for. The check for Swing won’t ever see the light of day on a JDK 1.0 system if you write it in the constructor of a JPanel subclass (think about it). Put the test early in the main flow of your application, before any GUI objects are constructed. Otherwise the code just sits there wasting space on newer runtimes and never gets run on Java 1.0 systems.