6 Tools

Java Class Search Path

Java applications are collections of Java classes and application resources that are built on one system and then potentially deployed on many different target platforms. Because the file systems on these target platforms can vary greatly from the development system, Java runtime environments use the Java class search path as a flexible mechanism for balancing the needs of platform-independence against the realities of different target platforms.

The Java class search path mechanism allows the Java virtual machine to locate and load classes from different locations that are defined at runtime on a target platform. For example, the same application could be organized in one way on a MacOS system and another on a Linux system. Preparing an application's classes for deployment on different target systems is part of the development process. Arranging them for a specific target system i s part of the deployment process.

The Java class search path defines a list of locations that the Java virtual machine uses to find Java classes and application resources. A location can be either a file system directory or a jar or Zip archive file. Locations in the Java class search path are delimited by a platform-dependent path separator defined by the path.separator system property. The Linux default is the colon ":" character.

The Java SE documentation^Foot 1  describes three related Java class search paths:

• The system or bootstrap classes comprise the Java platform. The system class search path is a mechanism for locating these system classes. The default system search path is based on a set of jar files located in JRE/lib.

• The extension classes extend the Java platform with optional packages like the JDBC Optional Package. The extension class search path is a mechanism for locating these optional packages. cvm uses the -Xbootclasspath command-line option to statically specify an extension class search path at launch time and the sun.boot.class.path system property to dynamically specify an extension class search path. The CDC default extension class search path is CVM/lib, except for some of the provider implementations for the security optional packages described in Security Optional Package which are stored in CVM/lib/ext. The Java SE default extension class search path is JRE/lib/ext.

• The user classes are defined and implemented by developers to provide application functionality. The user class search path is a mechanism for locating these application classes. Java virtual machine implementations like the CDC Java runtime environment can provide different mechanisms for specifying an Java class search path. cvm uses the -classpath command-line option to statically specify an Java class search path at launch time and the java.class.path system property to dynamically specify an user class search path. The Java SE application launcher also uses the CLASSPATH environment variable, which is not supported by the CDC Java runtime environment.

Native Method Search Path

The CDC HotSpot Implementation virtual machine uses the Java Native Interface^Foot 2  (JNI) as its native method support framework. The JNI specification leaves the platform-level implementation of native methods up to the designers of a Java virtual machine implementation. For the Linux-based CDC Java runtime environment described in this runtime guide, a JNI native method is implemented as a Linux shared library that can be found in the native library search path defined by the java.library.path system property.

Here is a simple example of how to build and use an application with a native method. The mechanism described below is very similar to the Java SE mechanism.

1. Compile a Java application containing a native method.

   % javac -source 1.4 -target 1.4 -bootclasspath lib/btclasses.zip HelloJNI.java
   

2. Generate the JNI stub file for the native method.

   % javah -bootclasspath lib/btclasses.zip HelloJNI
   

3. Compile the native method library.

   % gcc HelloJNI.c -shared -I${CDC_SRC}/src/share/javavm/export \
       -I${CDC_SRC}/src/linux/javavm/include -o libHelloJNI.so
   

   This step requires the CDC-based JNI header files in the CDC source release.

4. Relocate the native method library in the test directory.

   % mkdir test
   % mv libHelloJNI.so test
   

5. Launch the application.

   % cvm -Djava.library.path=test HelloJNI
   

   If the native method implementation is not found in the native method search path, the CDC Java runtime environment throws an UnsatisfiedLinkError.