Understanding Java ClassLoaders

If you’ve ever written a line of Java code, you’ve implicitly interacted with the unsung heroes of the Java Virtual Machine (JVM): ClassLoaders. These crucial components are responsible for dynamically loading classes into the JVM, enabling the flexibility and power that makes Java so widely used. But what exactly are they, and how do they work their magic? Let’s take a deep dive.

What is a ClassLoader?

At its core, a ClassLoader is an object responsible for finding and loading Java .class files into the JVM. When the JVM needs a class (e.g., when you use new MyClass() or reference a static member of a class), it doesn't just magically appear. Instead, the ClassLoader takes over. It's like a librarian for your Java application, fetching the books (classes) as they're requested.

The Delegation Model: A Hierarchy of Responsibility

Java ClassLoaders operate on a hierarchical delegation model. This means that when a ClassLoader is asked to load a class, it doesn’t immediately try to load it itself. Instead, it first delegates the request to its parent ClassLoader. Only if the parent cannot find and load the class will the current ClassLoader attempt to load it. This model prevents classes from being loaded multiple times and ensures a consistent classpath.

Java provides three built‑in ClassLoaders that form a parent‑child hierarchy. Imagine a chain of command:

Bootstrap Class Loader

This is the primordial ClassLoader, built into the JVM itself. It loads the core Java API classes (like java.lang.Object, String, etc.) from the rt.jar (runtime JAR) file, typically located in the <JAVA_HOME>/jre/lib directory. It has no parent. Java 9 introduced the Module System (Project Jigsaw), which fundamentally changed how the runtime image is structured and how classes are loaded. In Java 9, the rt.jar and tools.jar files were removed entirely. The runtime classes are now stored in a more efficient, internal format (JIMAGE files) located in the /lib/modules directory. in Java 9+, Bootstrap takes care of loading from Java Runtime Image (JRT) instead of rt.jar

Platform (Extension) Class Loader

The child of the Bootstrap ClassLoader, it loads classes from the Java extensions directory, usually <JAVA_HOME>/jre/lib/ext. This is where you might find optional packages or extensions installed globally for the JVM. In Java 8, this loader was primarily a container for “Extensions” — optional packages that weren’t part of the core but were standard across the platform. It loaded classes from the <JAVA_HOME>/jre/lib/ext directory or paths defined in the java.ext.dirs system property. This allowed developers to drop a JAR into the lib/ext folder, making those classes automatically visible to all applications without having to add them to the -classpath.

With the introduction of the Module System (Project Jigsaw), the “Extension Mechanism” was removed entirely. The loader was renamed to the Platform ClassLoader. It no longer looks at a specific directory. Instead, it loads classes from the modular runtime image (/lib/modules). In Java 8, the Bootstrap ClassLoader loaded almost all core classes with “all permissions.” In Java 9, for better security, many classes (like java.sql, java.xml, and javax.transaction) were moved to the Platform ClassLoader. It is responsible for loading Java SE platform modules that are not considered “core” enough for the Bootstrap loader.

System (Application) ClassLoader

This is the most common ClassLoader you’ll encounter. It’s responsible for loading classes from your application’s classpath. When you run a Java application, this is the ClassLoader that loads your own classes, as well as any third-party libraries you include. It’s the child of the Extension ClassLoader.

Get Kaustubh Saha’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In both Java 8 and Java 9+, the System ClassLoader (often called the Application ClassLoader) remains the primary loader for your own code and third-party libraries. However, its internal implementation and the way it delegates tasks underwent a major overhaul to support the module system. In Java 8, the System ClassLoader was a straightforward tool for loading everything on your “Application Classpath.” In Java 9, the System ClassLoader became “module-aware.” It is now responsible for loading the following:

• Application Modules: Modules you define on the module-path (--module-path).
• Unnamed Modules: Traditional JARs or classes placed on the class-path (--class-path).````````
• JDK Modules: A few specific JDK-internal tools (like jdk.compiler or jdk.jshell) that are not core enough for the Bootstrap or Platform loaders.

It doesn’t just ask its parent (the Platform ClassLoader) anymore. Because it knows which modules are assigned to which loaders, it can delegate directly to the Bootstrap or Platform loader if it knows the class belongs to a module they own.

Creating a Custom Class Loader

Java’s class loading mechanism is a fundamental part of its runtime environment, responsible for dynamically loading classes into the Java Virtual Machine (JVM). While the default class loaders (Bootstrap, Extension, and Application) handle most scenarios, there are times when you need more control over how classes are loaded. This is where creating a custom class loader comes in.

Why Custom Class Loaders?

Custom class loaders offer a range of powerful capabilities:

• Dynamic Loading/Unloading: Load classes from unconventional sources (databases, networks, encrypted files) or even dynamically unload classes (though true unloading is tricky due to garbage collection).
• Security Sandboxing: Isolate applications or modules from each other, preventing them from accessing each other’s classes or resources.
• Hot-Swapping: Update classes in a running application without restarting the entire JVM, crucial for long-running servers.
• Version Management: Load different versions of the same class or library simultaneously, avoiding “jar hell.”
• Obfuscation/Encryption: Load classes that are encrypted or obfuscated, decrypting them on the fly before they are defined.

To create a custom loader, you typically extend the java.lang.ClassLoader class. There are two primary methods to understand:

• findClass(String name): This is the recommended method to override. It is called by loadClass() only if the parent class loader cannot find the class.
• defineClass(String name, byte[] b, int off, int len): This final method converts an array of bytes into an instance of Class. You will call this inside your findClass implementation.

Here is a template for a class loader that reads class data from a specific file path.

import java.io.*;

public class MyCustomClassLoader extends ClassLoader {

    private String classPath;

    public MyCustomClassLoader(String classPath, ClassLoader parent) {
        super(parent);
        this.classPath = classPath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            // 1. Convert the class name to a file path
            byte[] classData = loadClassFromFile(name);
            
            // 2. Define the class using the byte array
            return defineClass(name, classData, 0, classData.length);
        } catch (IOException e) {
            throw new ClassNotFoundException("Could not load class " + name, e);
        }
    }

    private byte[] loadClassFromFile(String fileName) throws IOException {
        String path = classPath + File.separator + fileName.replace('.', File.separatorChar) + ".class";
        InputStream inputStream = new FileInputStream(path);
        ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
        
        int nextValue = 0;
        while ((nextValue = inputStream.read()) != -1) {
            byteStream.write(nextValue);
        }
        return byteStream.toByteArray();
    }
}

To use your new loader, you instantiate it and use reflection to trigger the class logic:

public class Main {
    public static void main(String[] args) throws Exception {
        MyCustomClassLoader loader = new MyCustomClassLoader("C:/myClasses", ClassLoader.getSystemClassLoader());
        Class<?> clazz = loader.loadClass("com.example.MyTargetClass");
        Object instance = clazz.getDeclaredConstructor().newInstance();
        System.out.println("Loaded: " + instance.getClass().getClassLoader());
    }
}

Important Considerations

• Delegation: Always pass a parent loader to your constructor (like getSystemClassLoader()) to ensure standard Java classes (like String or List) are still loaded by the built-in loaders.
• Visibility: Classes loaded by a child loader can see classes loaded by its parent, but the parent cannot see classes loaded by the child.

Every Class object in Java maintains a hidden, permanent reference to the ClassLoader instance that defined it.

When you call defineClass() (as seen in the custom loader example), the JVM creates a java.lang.Class instance on the heap. Inside the JVM's internal representation of that class, there is a field that points back to the ClassLoader object.

// Get the loader for a specific class
ClassLoader loader = MyClass.class.getClassLoader();

// For core classes (String, Integer), this returns null 
// because the Bootstrap Loader is native and doesn't have a Java object.
System.out.println(String.class.getClassLoader());

This link is critical for two reasons:

1. Namespace Isolation: A class is identified not just by its name (e.g., com.User), but by the tuple of (ClassName, ClassLoader). This is why you can load two different versions of the same class using two different loaders.
2. Dependency Loading: When Class A references Class B, the JVM automatically uses Class A’s loader to try and find Class B.