When the Java virtual machine needs access to a particular class, it is up to a class loader to provide the class. The class loader goes through the following steps to load and define a class:
If the class loader has already loaded this class, it should find the previously defined class object and return that object immediately.
The security manager is consulted to see if this program is allowed to access the class in question. If it is not, a security exception is thrown. This step may be considered optional.
Otherwise, an internal class loader is consulted to attempt to load
the class from the
CLASSPATH. If that succeeds,
the class loader returns. This ensures that classes within the Java
API will not be superseded by classes loaded from the network (or
The way this is done varies between 1.1 and 1.2. In 1.1, there is a single method
findSystemClass() method) that handles this
step. In 1.2, a class loader must delegate to another class loader to
find classes that are on the
CLASSPATH and call
findSystemClass() method to find classes
that are in the core API.
The security manager is consulted to see if this program is allowed to create the class in question. If it is not, a security exception is thrown. This step may be considered optional.
The class file is read into an array of bytes. The mechanism by which the class loader reads the file and creates the byte array will vary depending on the class loader (which, after all, ...