Understanding Java Context ClassLoader and How It Breaks the Parent Delegation Model

Java’s traditional parent‑delegation model loads classes through a hierarchy of class loaders, but the Context ClassLoader was introduced to allow certain code to break this hierarchy when needed.

One typical scenario is the SPI mechanism (e.g., JDBC drivers) where the platform class loader loads the JDBC API interfaces while third‑party driver implementations are loaded by the system/application class loader from the classpath.

Running the following code prints the class loaders of several JDBC‑related classes, illustrating that the platform classes are loaded by the bootstrap or platform loader and the driver implementation by the application loader:

System.out.println("java.sql.Connection :=> " + Connection.class.getClassLoader());
System.out.println("java.sql.DriverManager :=> " + DriverManager.class.getClassLoader());
System.out.println("java.sql.Driver :=> " + Driver.class.getClassLoader());
System.out.println("com.mysql.cj.jdbc.ConnectionImpl :=> " + com.mysql.cj.jdbc.ConnectionImpl.class.getClassLoader());

The output shows the separation of loaders, which means that at runtime the platform loader cannot see the driver implementation, causing NoClassDefFoundError unless the Context ClassLoader is used.

The Context ClassLoader can be obtained via Thread.currentThread().getContextClassLoader() and passed to reflective methods such as Class.forName(String, boolean, ClassLoader) to load classes with the desired loader.

ServiceLoader internally uses the current thread’s Context ClassLoader to locate service implementations, for example:

ServiceLoader
loadedDrivers = ServiceLoader.load(Driver.class);
Iterator
driversIterator = loadedDrivers.iterator();
while (driversIterator.hasNext()) {
    driversIterator.next();
}

In Spring Boot, running the application directly from an IDE (non‑packaged) uses the application class loader for both the application and the thread’s Context ClassLoader. When the application is packaged as an executable JAR, Spring Boot employs its own LaunchedURLClassLoader , which can cause class‑loading issues for third‑party JARs that rely on the thread Context ClassLoader.

The following Spring component logs the class loaders in both environments, demonstrating the difference:

package com.example.demo;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import java.util.concurrent.*;

@Component
@Slf4j
public class ThreadPoolConfig {
    @PostConstruct
    void init() throws ExecutionException, InterruptedException {
        log.info("Current class loader: {}", getClass().getClassLoader());
        log.info("Main class loader: {}", Demo1Application.class.getClassLoader());
        log.info("Thread context loader: {}", Thread.currentThread().getContextClassLoader());
        Thread thread = new Thread(() ->
            log.info("Thread context loader (new thread): {}", Thread.currentThread().getContextClassLoader()));
        thread.start();
        thread.join();
        CompletableFuture
future = CompletableFuture.runAsync(() ->
            log.info("CompletableFuture context loader: {}", Thread.currentThread().getContextClassLoader()));
        future.get();
    }
}

Images in the original article show the console output for both non‑packaged and packaged runs, confirming that the packaged run uses org.springframework.boot.loader.LaunchedURLClassLoader .

Spring Boot’s custom class loader introduces several pitfalls: many third‑party libraries expect the thread’s Context ClassLoader (or the system class loader) to load their classes, and asynchronous tasks executed by the default ForkJoinPool may inherit the system loader, causing NoClassDefFoundError when the expected loader is not used.

In summary, the Context ClassLoader breaks the parent‑delegation model to enable SPI mechanisms like JDBC driver loading, and developers need to be aware of class‑loader differences when running Spring Boot applications as executable JARs, especially when using custom thread pools or third‑party libraries.