Understanding Java Class Loading Mechanism and Tomcat’s ClassLoader Design

The article begins by reviewing the Java Virtual Machine’s class loading process, describing how class files are transformed into bytecode, verified, and linked into runtime types, and introducing the concept of class loaders as the modules that fetch binary class data.

It then explains the parent‑delegation model, where a request to load a class is first delegated to the parent class loader, detailing the three standard system class loaders: the Bootstrap ClassLoader ( java.lang.ClassLoader implementation in C++), the Extension ClassLoader ( sun.misc.Launcher$ExtClassLoader ), and the Application ClassLoader ( sun.misc.Launcher$AppClassLoader ).

The article discusses why the delegation model is necessary—to prevent multiple definitions of core classes like java.lang.Object —and how it can be intentionally broken, for example using the thread context class loader to allow parent loaders to request child loaders.

Next, it examines Tomcat’s classloader architecture, which adds four custom loaders on top of the standard hierarchy: commonLoader (loads classes for the container and all web apps), catalinaLoader (private to the Tomcat container), sharedLoader (shared among web apps but invisible to the container), and WebappClassLoader (private to each web application). It also mentions the JasperLoader used for individual JSP files to enable hot‑swap.

By comparing the delegation relationships, the article shows that Tomcat intentionally violates the parent‑delegation principle to achieve class isolation, version independence, and hot deployment of JSPs, and it concludes that Tomcat’s design indeed breaks the standard model.