The Java launcher, java, initiates the Java virtual machine. The virtual machine searches for and loads classes in this order:
rt.jarand several other important jar files.
.jarfiles located in the extensions directory.
In effect, these three search paths are joined to form a simple class path. This is similar to the "flat" class path previously used, but the current model has some important differences:
Bootstrap classes are the classes that implement the Java 2
Platform. Bootstrap classes are in the
several other jar files in the
These archives are specified by the value of the bootstrap class
path which is stored in the
property. This system property is for reference only, and should
not be directly modified.
It is very unlikely that you will need to redefine the bootstrap class path. The nonstandard option, -Xbootclasspath, allows you to do so in those rare cicrcumstances in which it is necessary to use a different set of core classes.
Note that the classes which implement the Java 2 SDK tools are
in a separate archive from the bootstrap classes. The tools archive
is the SDK's
/lib/tools.jar file. The development tools
add this archive to the user class path when invoking the launcher.
However, this augmented user class path is only used to execute the
tool. The tools that process source code, javac and
javadoc, use the original class path, not the augmented
version. (For more information, see How Javac
and Javadoc Find Classes, below.)
Extension classes are classes which extend the Java platform.
.jar file in the extension directory,
jre/lib/ext, is assumed to be an extension and is loaded
using the Java Extension
Framework. Loose class files in the extension directory will
not be found. They must be contained in a .jar file (or
.zip file). There is no option provided for changing the
location of the extension directory.
If the jre/lib/ext directory contains multiple
.jar files, and those files contain classes with the
same name, such as:
smart-extension1_0.jar contains class
smart-extension1_1.jar contains class smart.extension.Smart
the class that actually gets loaded is undefined.
User classes are classes which build on the Java platform. To find user classes, the launcher refers to the user class path -- a list of directories, JAR archives, and ZIP archives which contain class files.
A class file has a subpath name that reflects the class's
fully-qualified name. For example, if the class
com.mypackage.MyClass is stored under
/myclasses must be in
the user class path and the full path to the class file must be
myclasses/com/mypackage/MyClass.class. If the class
is stored in an archive named
myclasses.jar must be in the user class path, and the
class file must be stored in the archive as
The user class path is specified as a string, with a colon
:) separating the class path entries on
Solaris, and a semi-colon (
entries on Microsoft Windows systems. The java launcher puts
the user class path string in the
system property. The possible sources of this value are:
.", meaning that user class files are all the class files in the current directory (or under it, if in a package).
A JAR file usually contains a "manifest" -- a file which lists the contents of the JAR. The manifest can define a JAR-class-path, which further extends the class path (but only while loading classes from that JAR). Classes accessed by a JAR-class-path are found in the following order:
The javac and javadoc tools use class files in two distinct ways:
The class files used to resolve source code references are mostly the same class files used to run javac and javadoc. But there are some important exceptions:
tools.jarare only used to run javac and javadoc. The tools classes are not used to resolve source code references unless
tools.jaris in the user class path.
If a referenced class is defined in both a class file and source file, javadoc always uses the source file (javadoc never compiles source files). In the same situation javac uses class files, but automatically recompiles any class files it determines to be out of date. The rules for automatic recompilation are documented in the javac document for Windows or Unix.
By default, javac and javadoc search the user class path for both class files and source code files. If the -sourcepath option is specified, javac and javadoc search for source files only on the specified source file path, while still searching the user class path for class files.
To be used, a class or interface must be loaded by a class loader. Use of a particular class loader determines a security policy associated with the class loader.
A program can load a class or interface by calling the loadClass method of a class loader object. But usually a program loads a class or interface simply by referring to it. This invokes an internal class loader, which can apply a security policy to extension and user classes. If the security policy has not been enabled, all classes are "trusted". Even if the security policy is enabled, it does not apply to bootstrap classes, which are always "trusted."
When enabled, security policy is configured by system and user policy files. The Java 2 SDK includes a system policy file that grants "trusted" status to extension classes and places basic restrictions on user classes.
To enable or configure the security policy, refer to Security Features.
Note: Some security programming techniques that worked with the Java 1.1 platform are incompatible with the class loading model of the Java 2 Platform.