Hi friend,

Changes to CLASSPATH and -classpath

The class path has a default value and can be set by -classpath or CLASSPATH. In 1.1, it worked as follows:

* Class path default - The default value of the class path was (1) the path where Java platform classes resided (classes.zip or rt.jar), and (2) the current working directory (".", read as "dot").
* CLASSPATH - If the environment variable CLASSPATH was set, then the class path would (1) continue to contain classes.zip or rt.jar just the like default plus (2) the newly set value instead of the current working directory. [See Note 1]
* -classpath - If the option -classpath <path> was used, then <path> had to explicitly contain both (1) classes.zip or rt.jar and (2) application classes.

This behavior for -classpath was unfortunate because it meant users had to spell out the path to classes.zip:

C:> java -classpath C:\jdk-path\lib\classes.zip;\app\classes Application

We say unfortunate because this is inherently error-prone; the onus is on the user to ensure that the java command and the classes.zip were from the same JDK version. We ourselves have spent time debugging problems where a 1.1.4 java was trying to run 1.1.3 classes.zip, and this does not work because the native methods do not match.

The good news is that the -classpath option in 1.2 has taken on the same meaning as the CLASSPATH environment variable in 1.2, so you can now conveniently omit having to spell out the path to Java platform classes:

C:> java -classpath C:\app\classes Application

Some developers like to temporarily modify individual Java platform classes such as java\util\Vector.class, for purposes such as adding println statements to understand how the class works. In 1.2, these users would not be able to use the -classpath option to set the path to Java platform classes, as was possible in 1.1. For such uses, the -Xbootclasspath option must be used in 1.2.

Note 1 - Contrary to the bulleted statement above, we have seen users explicitly placing the path to classes.zip in their CLASSPATH environment variable, though this was not at all required.

New Class Search Paths

The earlier section showed that in JDK1.1, there was one search path used to find classes; its value could be set either through the -classpath option or the CLASSPATH environment variable.

In JDK 1.2, there are three search paths that are used to find classes:

1. The first place where java looks for classes is the bootstrap classpath. The value of this path can be examined by calling System.getProperty("sun.boot.class.path"). Note that the prefix "sun." shows that, at least for now, this property is specific to Sun's implementation.
2. The second place where java looks for classes is the extension directories. The list of directories can be examined by calling System.getProperty("java.ext.dirs").
3. The third and last place where java looks for classes is the application classpath. The value of this path can be examined by calling System.getProperty("java.class.path").

For a discussion of the new "extension directories" feature mentioned in item 2, refer to javac and The Extensions Framework documentation.

In 1.2, the argument you specify with the -classpath option is the value of the application classpath; it should contain the path to classes that constitute your application. The bootstrap classpath contains the path to Java platform classes that are contained in a file named rt.jar. This is discussed in the next section.