How Does Java Load Classes? Inside the JVM’s Parent‑Delegation Model

Overview

This article, based on JDK 8, analyzes the Java class‑loading process and the implementation principles of the parent‑delegation model.

What Is the JVM?

The Java Virtual Machine (JVM) is a specification for a virtual computer that abstracts hardware details, providing its own processor, stack, registers, and instruction set. By shielding platform‑specific differences, the JVM enables Java bytecode to run unchanged on many operating systems, embodying the “write once, run anywhere” principle.

Java Execution Process

Java code execution consists of two main steps:

The compiler translates .java source files into .class bytecode files.

The class loader loads those .class files into the JVM, where they are verified, linked, and executed.

Class Loading Process

The loading phase can be broken down into three sub‑phases:

Loading : a ClassLoader searches for and reads the binary .class file.

Linking , which includes:

Verification – checks the correctness of the class file.

Preparation – allocates memory for static fields and sets default values.

Resolution – replaces symbolic references in the constant pool with direct references.

Initialization : executes static initializers and assigns explicit static field values.

The article focuses on the first step—how the ClassLoader actually loads bytecode.

When Loading Occurs

Creating an instance of a class.

Accessing or assigning a static field.

Invoking a static method.

Using reflection to obtain a java.lang.Class object.

Initializing a subclass.

Running a class directly with the java command.

JVM loads classes lazily, i.e., on demand.

Types of ClassLoaders

Bootstrap ClassLoader – loads core library classes from the \lib directory; it is implemented in native code and cannot be referenced directly from Java.

Extension ClassLoader – loads classes from \lib\ext or directories specified by the java.ext.dirs system property.

Application (System) ClassLoader – loads classes from the user‑specified classpath; it is returned by ClassLoader.getSystemClassLoader().

Parent‑Delegation Model

When a ClassLoader receives a load request, it first delegates the request to its parent. Delegation continues up the hierarchy until the request reaches the Bootstrap ClassLoader. Only if the parent cannot find the class does the child attempt to load it itself.

A simple custom ClassLoader example illustrates this flow:

Compile a TestClassLoader class and note the .class file location.

Create a subclass of ClassLoader and override findClass, using defineClass to turn the byte array into a Class object.

Run the program and observe the parent‑child relationship in the debugger (AppClassLoader → ExtClassLoader → Bootstrap).

Why Use Parent Delegation

Introduced after JDK 1.2, the model guarantees a single definition of core classes (e.g., java.lang.Object) in memory, preventing conflicts and protecting the core API from being overridden by user‑defined classes.

Breaking the Model

Although widely adopted, some containers (e.g., Tomcat) deliberately break the delegation rule to isolate web applications, allowing different versions of the same library to coexist and enabling hot‑reloading of JSPs.

Conclusion

The article described the purpose of ClassLoaders, detailed the loading‑link‑initialize phases, explained the parent‑delegation mechanism as implemented in ClassLoader.loadClass, and discussed scenarios where deviating from the model is justified.