Java2 ClassLoader

1. Java2 ClassLoader Delegation Model

The Java2 ClassLoader model is a "delegating parent" model, meaning that when a ClassLoader is asked to load a class, it first delegates the opportunity to load the requested class to its parent ClassLoader. Only if the parent (a) hasn't already loaded the Class and (b) can't load the Class does the child ClassLoader get the opportunity to provide the Class requested, if it can. This means that ClassLoaders form a hierarchical tree, with the "bootstrap" ClassLoader (the only ClassLoader in the JVM with a "value" of null) as the root of the tree. Any ClassLoader constructed within user code must have a parent ClassLoader; if none is provided in the ClassLoader constructor call, the ClassLoader constructors assume this ClassLoader's parent to be the "system" or ClassLoader.

Implicitly associated with each loaded Class in a JVM is the ClassLoader that loaded it. It is this
ClassLoader that is returned from the Class method getClassLoader. Each Class is associated with
one-and-only-one ClassLoader, and this is not mutable-Class objects can't change the ClassLoader
reference to point to another ClassLoader.


2. Java2/JDK1.2 Default ClassLoader Architecture

The Java2 system provides for loading code from one of three places by default: the core library, the Extensions directory (or directories, if you modify the java.ext.dirs property to include multiple subdirectories), and from the directories and/or .jar/.zip files found along the java.class.path property, which in turn comes from the CLASSPATH environment variable. Each of these three locations is in turn covered by its own ClassLoader instance: the core classes, by the bootstrap ClassLoader, the Extensions directory/directories by the extension ClassLoader, and the CLASSPATH by the system or application ClassLoader.

The bootstrap ClassLoader is implemented as part of the VM itself, and cannot be instantiated by Java
code. It is this ClassLoader that brings the core Java classes into the VM, allowing the rest of the JVM to
load itself. (Take a second to think about this-in order to construct a ClassLoader, which extends Object,
the JVM must load the Object class. But in order to do this, it requires a ClassLoader with which to load
it!) Normally, this means loading code from the "rt.jar" file in the jdk/jre/lib subdirectory, but under the
Sun JVM, this is actually controlled by the boot.class.path property.

The extension ClassLoader, the first child of the boostrap ClassLoader, is implemented in pure Java
code. As already mentioned, the extension ClassLoader's primary responsibility is to load code from the
JDK's extension directories. This in turn provides users of Java the ability to simply "drop in" new code
extensions (hence the name "Extension directory"), such as JNDI or JSDT, without requiring
modification to the user's CLASSPATH environment variable.

The system, or application, ClassLoader, is the ClassLoader returned from the static method
ClassLoader.getSystemClassLoader. This is the ClassLoader responsible for loading code from
the CLASSPATH, and will, by default, be the parent to any user-created or user-defined ClassLoader in
the system.


3. Class.forName vs ClassLoader.loadClass

There are some subtle differences between these two
APIs. The method call CL.loadClass(C), where CL is our ClassLoader and C is the name of the
class to load, queries the ClassLoader directly for the class by name. This in turn relies on ClassLoader
delegation to ask the bootstrap ClassLoader to determine if the class has already been loaded.
Conversely, the method call Class.forName(C, false, CL) uses the VM's internal class resolution
mechanism to do the actual loading. Among other things, this allows Class.forName to support the
loading of arrays of Classes as a type; for example, calling CL.loadClass("[C;") will result in
failure, where doing the same with Class.forName("[C;", false, CL) will succeed.