Understanding Java Class Loading, the Parent Delegation Model, and Tomcat’s Custom ClassLoaders

We explore four main topics: what the class‑loading mechanism is, what the parent‑delegation model is, how the model can be broken, and how Tomcat designs its own class‑loaders.

Java virtual machines load class bytecode from .class files into memory, verify it, and transform it into runtime types; the component that performs this loading is called a ClassLoader .

Each class is uniquely identified by the combination of its fully‑qualified name and the ClassLoader that loaded it, giving every loader its own namespace.

The parent‑delegation model defines two primary loaders: the Bootstrap ClassLoader (implemented in C++ and part of the VM) and all other loaders that extend the abstract java.lang.ClassLoader . The three standard system loaders are the Bootstrap, Extension ( sun.misc.Launcher$ExtClassLoader ), and Application ( sun.misc.Launcher$AppClassLoader ) loaders.

This model ensures that core classes like java.lang.Object are loaded only once by the top‑level loader, preventing multiple incompatible versions from existing in the same JVM.

The delegation logic resides in java.lang.ClassLoader 's loadClass method: it first checks if the class is already loaded, then delegates to the parent loader, and only if the parent fails (throwing ClassNotFoundException ) does it invoke its own findClass method.

Although widely adopted, the model can be broken in three notable ways: before JDK 1.2, via the Thread Context ClassLoader (used by services like JNDI, JDBC, JCE, etc.), and for hot‑swap/module replacement scenarios.

Tomcat implements a distinct class‑loading hierarchy to satisfy web‑application isolation, hot‑swap of JSPs, and shared library usage. Its loaders include CommonClassLoader , CatalinaClassLoader , SharedClassLoader , and WebappClassLoader , which load classes from /common/* , /server/* , /shared/* (merged into lib after Tomcat 6), and /WebApp/WEB-INF/* respectively.

Each web application gets its own WebappClassLoader , and each JSP gets a dedicated JasperLoader that can be discarded and recreated when the JSP changes, enabling hot‑swap.

Because Tomcat’s web‑app loaders load classes directly without delegating to their parents, Tomcat intentionally violates the parent‑delegation model to achieve class‑loader isolation and dynamic reloading.