Recipe 2.3 Writing JDK Release-Dependent Code


Problem

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

Solution

Don't do this.

Discussion

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,[1] you could use:

[1] Old-timers will remember that on the preliminary Swing releases, the name of this class was com.sun.java.swing.JButton.

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.

As for what the class Class actually does, we'll defer that until Chapter 25.



Java Cookbook
Java Cookbook, Second Edition
ISBN: 0596007019
EAN: 2147483647
Year: 2003
Pages: 409
Authors: Ian F Darwin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net