The Java launcher, java, initiates the Java virtual machine.
The virtual machine searches for and loads classes in this order:
Bootstrap classes - Classes that comprise the Java platform,
including the classes in rt.jar
and i18n.jar.
Extension classes - Classes that use the Java Extension mechanism.
These are bundled as .jar
files located in the extensions directory.
User classes - Classes defined by developers and third parties that
do not take advantage of the extension mechanism. You identify the location of
these classes using the -classpath option on the command line
the preferred method) or by using the CLASSPATH environment variable.
(See Setting the Classpath for Windows or
Solaris.)
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:
It is relatively difficult to accidentally
"hide" or omit the bootstrap classes.
In general, you only have to specify the location of user classes.
Bootstrap classes and extension classes are found "automatically".
The tools classes are now in a separate archive (tools.jar)
and can only be used if included in the user class path (to be explained shortly).
How the Java Launcher Finds Bootstrap Classes
Bootstrap classes are the classes that implement the Java
2 Platform. Bootstrap classes are in the rt.jar
and i18n.jar archives in
jre/lib directory. These archives are specified by
the value of the bootstrap class path which is stored in the
sun.boot.class.path system 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 separate archive from the bootstrap classes. The
tools archive is the 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 orginal
class path, not the augmented version. (For more information,
see How Javac and Javadoc Find
Classes, below.)
How the Java Launcher Finds Extension Classes
Extension classes are classes which
extend the Java platform. Every .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.
How the Java Launcher Finds User Classes
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
full-qualified name. For example, if the class
com.mypackage.MyClass is stored under
/myclasses, then /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, then myclasses.jar
must be in the user class path, and the class file must be
stored in the archive as
com/mypackage/MyClass.class.
The user class path is specified as a string,
with a colon (:) separating the class path
entries on Solaris, and a semi-colon (;)
separating entries on Win32 systems. The java launcher puts the user class path
string in the java.class.path system
property. The possible sources of this value are:
The default value, ".",
meaning that user class files are all class files in the
current directory (or under it, if in a package).
The value of the CLASSPATH environment variable,
which overrides the default value.
The value of the -cp or -classpath command
line option, which overrides both the default value and the
CLASSPATH value.
The JAR archive specified by the -jar option, which
overrides all other values. If this option is used, all user
classes come from the specified archive.
How the Java Launcher Finds JAR-class-path Classes
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:
In general, classes referenced by a JAR-class-path entry are
found as though they were part of the JAR file. The JAR files
that appear in the JAR-class-path are searched after any earlier
class path entries, and before any entries that appear later
in the class path.
However, if the JAR-class-path points to a JAR file that was already
searched (for example, an extension, or a JAR file that was listed
earlier in the class path) then that JAR file will not be searched again.
(This optimization improves efficiency and prevents circular searches.)
Such a JAR file is searched at the point that it appears, earlier
in the class path.
If a JAR file is installed as an extension in the SDK's ext
subdirectory, then any JAR-class-path it defines is ignored. All the
classes required by an extension are presumed to be part of the SDK or
to have themselves been installed as extensions.
How Javac and JavaDoc Find Classes
The javac and javadoc tools use class files
in two distinct ways:
Like any Java application, javac and javadoc
must load various class files in order to run.
To process the source code they operate on, javac
and javadoc must obtain information on object types
used in the source code.
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:
Both javac and javadoc often resolve
references to classes and interfaces that having nothing to do
with the implementation of javac or
javadoc. Information on referenced user classes and
interfaces may be present in the form of class files, source
code files, or both.
The tools classes in tools.jar are only used
to run javac and javadoc. The tools classes are
not used to resolve source code references unless
tool.jar is in the user class path.
A programmer may want to resolve boot class or extension
class references using an alternative Java platform
implementation. Both javac and javadoc support
this with their -bootclasspath and -extdirs
options. Use of these options does not modify the set of class
files used to run the javac or javadoc tools
themselves.
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 Solaris.
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 only the specified source file path.
Class Loading and Security Policies
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.