The class loading component is fundamental to the Java virtual machine. Though developers generally have a good grasp of the basics of class loading, when a problem occurs, they may have a hard time diagnosing and determining a solution. In this four-part article series, we discuss the various class loading problems that you may encounter in your Java development and illustrate why they occur and how to resolve them. These insights should help you understand and resolve common Java exceptions, such as NoClassDefFoundError and ClassNotFoundException, in addition to more challenging problems, such as class loader constraint violations and deadlocks. In this first article, we describe in detail how Java class loading works and discuss the tools available in the JVM to help you diagnose class loading problems.

Class loaders are responsible for loading classes into the Java Virtual Machine (JVM). Simple applications can use the Java platform's built-in class loading facility to load their classes; more complex applications tend to define their own custom class loaders. No matter what kind of class loader you're using, however, there are many problems that can occur in the class loading process. If you want to avoid such problems, you need to understand the fundamental mechanics of class loading. When problems do occur, an appreciation of the available diagnostic features and debugging techniques should help you resolve them.

In this series of articles, we'll provide an in-depth look at class loading problems and use comprehensive examples to illustrate them. The first section of this introductory article describes the fundamentals of class loading; the second introduces some JVM debugging features. The next three articles in this series will focus on resolving class loading exceptions and illustrate some of the trickier class loading problems that you may encounter.

Fundamentals of class loading
This section describes the core concepts of class loading to provide a knowledge base for the rest of this series.

Class loader delegation
The class loader delegation model is the graph of class loaders that pass loading requests to each other. The bootstrap class loader is at the root of this graph. Class loaders are created with a single delegation parent and looks for a class in the following places:

• Cache
• Parent
• Self

Because the parent class loader is always given the opportunity to load a class first, the class is loaded by the class loader nearest the root. This means that all core bootstrap classes are loaded by the bootstrap loader, which makes sure that the correct versions of classes such as java.lang.Object are loaded. This also has the effect of only allowing a class loader to see classes loaded by itself or its parent or ancestors; it cannot see classes loaded by its children.

Figure 1 shows the three standard class loaders.

Unlike all other class loaders , the bootstrap class loader (also known as the primordial class loader) cannot be instantiated by Java code. (Often, this is because it is implemented natively as part of the VM itself.) This class loader loads the core system classes from the boot classpath, which is normally the JAR files located in the jre/lib directory. However, you can modify this classpath using the -Xbootclasspath command-line options (which we describe later).

The extension class loader (also known as the standard extensions class loader) is a child of the bootstrap class loader. Its primary responsibility is to load classes from the extension directories, normally located the jre/lib/ext directory. This provides the ability to simply drop in new extensions, such as various security extensions, without requiring modification to the user's classpath.

The system class loader (also known as the application class loader) is the class loader responsible for loading code from the path specified by the CLASSPATH environment variable. By default, this class loader is the parent of any class loader created by the user. This is also the class loader returned by the ClassLoader.getSystemClassLoader() method.

Classpath options
Table 1 summarizes the command-line options for setting the classpaths of the three standard class loaders:

The phases of class loading
The loading of a class can essentially be broken down into three phases: loading, linking, and initializing.

Most, if not all, problems relating to class loading can be tracked down to a problem occurring in one of these phases. Therefore, a thorough understanding of each phase helps in the diagnosing of class loading problems. The phases are illustrated in Figure 2:

The loading phase consists of locating the required class file (by searching though the respective classpaths) and loading in the bytecode. Within the JVM, the loading process gives a very basic memory structure to the class object. Methods, fields, and other referenced classes are not dealt with at this stage. As a result, the class is not usable.

Linking is the most complicated of the three phases. It can be broken down into three main stages:

• Bytecode verification. The class loader does a number of checks on the bytecodes of the class to ensure that it is well formed and well behaved.
• Class preparation. This stage prepares the necessary data structures that represent fields, methods, and implemented interfaces that are defined within each class.
• Resolving. In this stage, the class loader loads all the other classes referenced by a particular class. The classes can be referenced in a number of ways:
  - Superclasses
  - Interfaces
  - Fields
  - Method signatures
  - Local variables used in methods

At the end of these three phases, a class is fully loaded and is ready for use. Note that class loading can be performed in a lazy manner and therefore some parts of the class loading process may be done on first use of the class rather than at load time.

Explicit vs. implicit loading
There are two ways in which classes can be loaded -- explicitly or implicitly -- with subtle variations between the two. Explicit class loading occurs when a class is loaded using one of the following method calls:

• cl.loadClass() (where cl is an instance of java.lang.ClassLoader)
• Class.forName() (the starting class loader is the defining class loader of the current class)

Implicit class loading occurs when a class is loaded as result of a reference, instantiation, or inheritance (not via an explicit method call). In each of these cases, the loading is initiated under the covers and the JVM resolves the necessary references and loads the class. As with explicit class loading, if the class is already loaded, then a reference is simply returned; otherwise, the loader goes through the delegation model to load the class.