How classes are found
khushbu
How the Java Launcher Finds Classes
How the Java Launcher Finds Bootstrap Classes
How the Java Launcher Finds Extension Classes
How the Java Launcher Finds User Classes
How the Java Launcher Finds JAR-class-path Classes
How Javac and Javadoc Find Classes
Class Loading and Security Policies
How the Java Launcher Finds Classes
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.
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.extension.Smart
smart-extension1_1.jar contains class smart.extension.Smart
the class that actually gets loaded is undefined.
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.
--------------------------------------------------------------------------------
Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.
Java Software
Parag Shah
That was very informative. Also check out this link: http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html
--
Regards
Parag