Examining the Standard J2SE Class Loaders

Since J2SE 1.2, the JVM has used three distinct class loaders.

• Bootstrap class loader

• Extension class loader

• System class loader

These class loaders sit in a hierarchy with the bootstrap class loader at the top and the system class loader at the bottom. They have parent-child relationships, so the parent of the system class loader is the extension class loader. The bootstrap class loader is written in native code and is included in the JVM, and the other two class loaders, as is the case with Tomcat’s class loaders, are written in Java.

The Bootstrap Class Loader

The JVM uses the bootstrap class loader to load those Java classes that are necessary for it to function. This means the bootstrap class loader loads all the core Java classes (such as java.lang.* and java.io.*).

As noted previously, the bootstrap class loader is written in native code, so it solves the circular problem of loading Java-based class loaders when the initial class loader itself must be loaded. The classes it loads are located in different locations depending on the JVM vendor. They’re always in JAR files, and Sun stores them in JAVA_HOME/jre/lib/.

The Extension Class Loader

J2SE 1.2 introduced the standard extension mechanism. Normally, when developers want the JVM to load class files that aren’t in the bootstrap classpath, they use the CLASSPATH environment variable. Sun introduced the standard extension mechanism as an alternative method; you can drop JAR files into a standard extension directory, and the JVM will automatically find them.

The extension class loader is responsible for loading all the classes in one or more extension directories. Just as the bootstrap class loader’s path can vary on different JVMs, so can the standard extension path. On Sun’s JVM, the standard extension directory is JAVA_HOME/jre/lib/ext/.

One advantage with the standard extension mechanism is that developers don’t have to struggle with a huge CLASSPATH environment variable as they add more and more libraries to their systems.

The System Class Loader

The system class loader places its classes in those directories and JAR files specified in the CLASSPATH environment variable. The system class loader is also used to load an application’s main class and is the default class loader for loading any other classes not covered by the previous two class loaders.

The Delegation Model

So, J2SE has three different class loaders, but how does the JVM know which class loader to use? The answer is in the delegation model. In every version of Java since J2SE 1.2, whenever a class loader receives a request to load a class, it first asks its parent to fulfill the request. (In other words, it delegates the request to its parent class loader.) If the parent loads the class successfully, then the resulting class object is returned. The original class loader attempts to load the class itself only if its parent (and its parent’s parent, and so on) fails to load the class.

Thus, when a developer references a class in a Java program, the JVM will automatically route a request to the system class loader to load the class. The system class loader will then request that the extension class loader load the specified class, which in turn will request that the bootstrap class loader load the class. The process stops with the bootstrap class loader, which will then check the core Java libraries for the requested class.

If the class doesn’t exist in the core libraries, then the extension class loader will check the standard extensions for the class. If it’s still not found, then the system class loader will check the locations specified by the CLASSPATH variable for the class. If the class still could not be located, then a ClassNotFoundException will be thrown.

The Endorsed Standards Override Mechanism

Following the previous discussion, when a developer uses a class in a Java application, the request to load it is passed up the class loader hierarchy. This means that if the bootstrap class loader can load a class, it will load it even if the class is present in the scope of another class loader. For example, J2SE 1.4 and 5 includes a Java API for XML Processing (JAXP) XML parser as standard, which as a consequence is loaded by the bootstrap class loader. In this case, developers can’t place their preferred XML parser in an application’s CLASSPATH because the system class loader always defers to the bootstrap class loader.

The Endorsed Standards Override Mechanism solves this problem. If a developer places JAR files that replace the standard XML parser in some specific location, the bootstrap class loader will load their class files instead. In J2SE 1.4 and 5, this location is JAVA_HOME/lib/endorsed/. Users can change the path for this mechanism by setting the java.endorsed.dirs property.

Before you start thinking about replacing any of the core libraries, Java allows you only to override certain packages. You can find the complete list of packages in the J2SE 1.4 documentation (http://java.sun.com/j2se/1.4.2/docs/guide/standards/) and the J2SE 5 documentation (http://java.sun.com/j2se/1.5.0/docs/guide/standards/). In summary, you can override only the CORBA classes and the XML parser classes with this mechanism.