library
advancedClassLoader Hierarchy
Understand how Java loads classes, the delegation model, and when custom classloaders are needed.
Java uses a hierarchical ClassLoader system to load .class files into the JVM at runtime.
ClassLoader hierarchy = a corporate approval chain. A request (load class) goes up to the CEO (Bootstrap). If the CEO can handle it, done. If not, it goes to VP (Platform), then to Manager (Application). The top levels handle core business; lower levels handle specialized tasks.
Key Concepts
1
Built-in ClassLoaders (Java 9+ module system):
1. Bootstrap ClassLoader: loads core Java classes (java.lang, java.util) from the JDK. Written in native code.
2. Platform ClassLoader (was Extension in Java 8): loads platform modules (java.sql, java.xml, javax.*).
3. Application ClassLoader: loads classes from the classpath (your application code, third-party JARs).
2
Delegation model (parent-first): when asked to load a class, a classloader first delegates to its parent. Only if the parent can't find the class does the child attempt to load it. This ensures core Java classes are always loaded by the Bootstrap loader (can't be overridden).
3
Each class is identified by its fully qualified name AND its classloader. The same .class file loaded by two different classloaders produces two different Class objects — they can't cast to each other (ClassCastException).
4
Custom ClassLoaders: needed for hot-reloading (load a new version of a class without restarting), plugin systems (isolate plugins from each other), application servers (isolate deployed WAR files), and sandboxing (restrict what classes are visible).