How Does Class Loading Work in Java?

Class loading has three stages, and each has a distinct job.

Loading finds the bytes for the class and defines a java.lang.Class object for it. The bytes come from somewhere the loader knows about — the runtime image, a jar, the classpath, or a custom source. For most classes the loading is lazy: the class is not loaded until the program first uses it, which is why a program with an unreachable branch referencing a missing class still runs.

Linking prepares the class for execution, in three sub-steps. Verification checks that the bytecode obeys the type rules and cannot do anything unsafe — this is the step that stops a hand-crafted class file from reaching outside the sandbox. Preparation allocates memory for the static fields and sets them to their default values, so a static int is zero at this point even if the source says it starts at 42. Resolution replaces the symbolic references in the constant pool with direct references to the classes, methods and fields they name.

Initialisation runs the class's static initialiser blocks and static field initialisers, in source order, and then the class is ready to be used. This is the point at which a static int finally becomes 42.

Two details worth remembering. A class is initialised exactly once, and the JVM guarantees that by locking on the class's own monitor, so two threads racing to initialise the same class cannot both run the initialiser. And initialisation is triggered on first active use — instantiating it, accessing a static field, or invoking a static method — not merely by loading it.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) throws ClassNotFoundException {
        Class<?> c = Main.class;
        System.out.println("name        : " + c.getName());
        System.out.println("loader      : " + c.getClassLoader());
        System.out.println("superclass  : " + c.getSuperclass().getName());
        System.out.println("package     : " + c.getPackageName());
        System.out.println("interfaces  : " + c.getInterfaces().length);

        // Loading happens on first use.
        Class<?> loaded = Class.forName("java.lang.String");
        System.out.println("loaded      : " + loaded.getName());
        System.out.println("same class  : " + (loaded == String.class));
    }
}

The parent delegation model says that when a class loader is asked to load a class, it first asks its parent to do it, and only loads the class itself if the parent cannot find it. The hierarchy runs from the bootstrap loader, through the platform loader, down to the application loader, which handles everything on the classpath. Application code can also install its own custom loaders, which sit alongside or below the built-in ones.

The reason it exists is security and consistency. Because the delegation always goes upward first, the core classes are always loaded by the bootstrap loader, from the runtime image itself. You cannot override java.lang.String by putting your own version on the classpath — the application loader asks the platform loader, which asks the bootstrap loader, which finds the real one and returns it. Without delegation, any application could shadow a core class and replace java.lang.String with its own implementation, and every type check in the runtime would be suspect.

Two details are commonly asked about. The delegation is not absolute: a class loader may choose to load the class itself rather than delegating, and the ClassLoader.loadClass method is protected precisely so that custom loaders can override the behaviour. And parent-last delegation, which searches the class's own path first, is a deliberate technique used by application servers and by frameworks that need to load several versions of the same library side by side.

One more point that ties this to a common bug: a class is identified by the pair of its binary name and the loader that defined it. Two classes with identical names loaded by different loaders are entirely different types, so casting between them fails with a ClassCastException even though the names match.