How to Break Java’s Parent Delegation Mechanism and Why It Matters

Introduction

Recently a friend asked why JDBC breaks the parent delegation mechanism. This article explains the parent delegation mechanism in Java, its purpose, and common scenarios where it is intentionally broken.

1. Why the Parent Delegation Mechanism Exists

Before Java runs, source code is compiled to bytecode (class files). The JVM loads these bytecode into the runtime data area using a ClassLoader. The loading process includes verification, preparation, resolution, and initialization.

When loading classes, we need to ensure:

Classes are not loaded multiple times.

Class loaders can be customized.

Loaded classes are safe.

The integrity of loaded classes is preserved.

These requirements are satisfied by the parent delegation mechanism.

2. What Is the Parent Delegation Mechanism?

The mechanism works by having a class loader delegate the loading request to its parent first; only if the parent cannot load the class does the current loader attempt to load it. This ensures uniqueness, prevents duplicate loading, and improves security.

Java defines three built‑in class loaders: Bootstrap Class Loader: loads core libraries from $JAVA_HOME/jre/lib, implemented in native code. Extension Class Loader: loads libraries from $JAVA_HOME/lib/ext. Application (System) Class Loader: loads classes from the application classpath.

3. Breaking the Parent Delegation Mechanism

Sometimes flexibility is needed, so custom class loaders are introduced. To break the delegation, one can override loadClass (or findClass) in a subclass of ClassLoader. The following are common scenarios:

3.1 Thread Context Class Loader (JNDI)

JNDI needs to load provider implementations that are not visible to the bootstrap loader. Setting a thread context class loader via Thread.setContextClassLoader() allows JNDI to load these classes, effectively breaking the parent delegation.

3.2 JDBC Drivers

JDBC drivers are loaded dynamically. Since driver implementations reside in application‑specific JARs, the bootstrap loader cannot load them. Using the thread context class loader or the application class loader enables loading, bypassing the parent delegation.

3.3 Tomcat Container

Tomcat must isolate web applications while sharing common libraries. It uses a hierarchy of class loaders (CommonClassLoader, CatalinaClassLoader, SharedClassLoader, WebAppClassLoader) that does not follow strict parent delegation, allowing each web app to load its own versions of libraries.

3.4 OSGi and Hot Deployment

OSGi bundles are loaded by independent class loaders with no fixed delegation hierarchy, enabling hot deployment and module replacement without restarting the JVM.

4. Summary of the Modified Loading Process

The modified loading sequence checks custom, application, extension, and bootstrap loaders in order, delegating to the first loader that can load the class; if none can, a ClassNotFoundException is thrown.