Understanding Java's Parent Delegation Model for Class Loaders
The article explains Java's parent delegation model for class loaders, its benefits for stability and security, how to break it by customizing loadClass or using thread‑context class loaders, and illustrates common scenarios such as JNDI, JDBC and Tomcat's own class‑loader hierarchy.
When a class needs to be loaded in Java, the ClassLoader hierarchy determines which loader actually performs the loading, and this is governed by the parent delegation model.
The ClassLoader class uses a delegation model to search for classes and resources. Each instance has an associated parent class loader. When requested to find a class or resource, a ClassLoader instance will delegate the search to its parent before attempting to find it itself. The built‑in bootstrap class loader has no parent and may serve as the parent of other loaders.
The model implies three key points:
ClassLoader uses a delegation model to search for classes and resources.
All class loaders except the bootstrap loader must have a parent.
A ClassLoader instance delegates the search to its parent before trying to load the class itself.
Benefits of the parent delegation model include preventing duplicate class loading (different loaders would otherwise create distinct class objects) and protecting core Java APIs from being overridden.
To break the model, developers can define a custom class loader and override loadClass() , or use the thread‑context class loader (set via Thread.setContextClassLoader() ) to load classes outside the normal delegation chain.
Common scenarios that break the model
JNDI : Uses the thread‑context class loader to load service provider implementations that the bootstrap loader cannot see.
JDBC : Driver implementations are loaded by the thread‑context class loader because they reside in application‑specific JARs.
Tomcat : Requires a more flexible hierarchy to isolate web applications while sharing common libraries, leading to a custom set of loaders (CommonClassLoader, CatalinaClassLoader, SharedClassLoader, WebAppClassLoader) that deviate from strict parent delegation.
Tomcat's class‑loader hierarchy can be visualised as:
CommonClassLoader – visible to both the container and web apps.
CatalinaClassLoader – private to the Tomcat container.
SharedClassLoader – shared among web apps but invisible to the container.
WebAppClassLoader – private to each web application, allowing different versions of the same library to coexist.
Top Architecture Tech Stack
Sharing Java and Python tech insights, with occasional practical development tool tips.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.