Java class loading process

It’s good to know, how Java class loading works, when you have to develop in Java. Basic understanding of class loading process helps every Java developer to deal with several ClassLoader related Exceptions.

Class loader delegation

The loading of Java classes is performed by class loaders (CL), they are responsible for loading classes into the 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.
The class loaders in Java are organized in a tree. By request a class loader determines if the class has already been loaded in the past, looking up in its own cache. If the class is present in the cache the CL returns the class, if not, it delegates the request to the parent. If the parent is not set (is Null) or can not load the class and throws a ClassNotFoundException the classloader tries to load the class itself and searches its own path for the class file. If the class can be loaded it is returned, otherwise a ClassNotFoundException is thrown. The cache lookup goes on recursively from child to parent, until the tree root is reached or a class is found in cache. If the root is reached the class loaders try to load the class and unfold the recursion from parent to child. Summarizing that we have following order:

• Cache
• Parent
• Self

This mechanism ensures that classes tending to be loaded by class loaders nearest to the root. Remember, that parent class loader is always has the opportunity to load a class first. It is important to ensure that core Java classes are loaded by the bootstrap loader, which guarantees that the correct versions of classes such as java.lang.Object are loaded. Furthermore it ensures, that one class loader sees only classes loaded by itself or its parent (or further ancestors) and it cannot see classes loaded by its children or siblings!
The picture illustrates the hierarchy of class loaders. Root loader is bootstrap class loader which has native implementation and cannot be instantiated by Java code.

It is followed by extension class loader, which is primary responsibility to load classes from the extension directories and provides ability to simply drop in new JVM extensions, without requiring modification to the user’s classpath. The system or application class loader responsible for loading classes from the path specified by the CLASSPATH environment variable. This class loader will be returned by the ClassLoader.getSystemClassLoader() method.

Phases of class loading

The are three phases of concrete class loading: physical loading, linking, and initializing.

1. In in first phase of physical loading required class file will be searched in specified classpaths. If the file is found it is read and the bytecode is loaded. This process gives a basic memory structure to the class object, such concepts like methods, fields, and other referenced classes are not known at this stage.
2. Linking can be broken down into three main stages, because it is complex phase:
   1. Bytecode verification through class loader, which executes a number of checks on the bytecodes.
   2. Class preparation. This stage prepares the necessary data structures that represent fields, methods and implemented interfaces that are defined within the class.
   3. Resolving of all the other classes referenced by a particular class. The classes can be referenced in a number of ways:
      • Superclasses
      • Interfaces
      • Field types
      • Types in method signatures
      • Types of local variables used in methods
3. During the initializing phase any static initializers contained within a class are executed so that, static fields are initialized to their default values.

It is interesting, 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.

Exceptions

The biggest challenge in dealing with class-loading problems is that problems rarely manifest themselves during the class-loading process but rather during the usage of a class later on. In following shown two class loading related exceptions, with potential causes

• ClassNotFoundException
  • An archive, directory, or other source for the classes was not added to the class loader asked to load the class, or to its parent.
  • A class loader’s parent is not set correctly.
  • The wrong class loader is used to load the class in question.
• NoClassDefFoundError
  • An archive, directory, or other source for the classes was not added to the class loader asked to load the class, or to its parent.
  • A class loader’s parent is not set correctly.
  • Symbolic links in a class are unaccessible by the containing class’s class loader, such as a child class loader.

References:

• [2005,techreport] bibtex
  L. Shankar and S. Burns, "Demystifying class loading problems, Part 1: An introduction to class loading and debugging tools," 2005.

• [2004,techreport] bibtex
  A. Schaefer, "Inside Class Loaders: Debugging," 2004.

[2003,techreport] bibtex

A. Schaefer, "Inside Class Loaders," 2003.