ClassLoader Hierarchy and Custom Loaders
Understand bootstrap, platform, and application class loaders and write a custom ClassLoader.
ClassLoader Hierarchy and Custom Loaders is a free Java Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Java Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The ClassLoader Hierarchy
The JVM uses a hierarchy of ClassLoaders. Each loader has a parent; before loading a class itself, it delegates to the parent (parent-first delegation model).
Bootstrap ClassLoader
The bootstrap ClassLoader loads core JDK classes (java.lang.*, java.util.*). It is implemented in native code and has no Java parent; getParent() returns null.
ClassLoader cl = String.class.getClassLoader();
System.out.println(cl); // null (bootstrap ClassLoader)Platform ClassLoader (Java 9+)
The Platform ClassLoader (formerly Extension ClassLoader) loads modules from the JDK that are not in the bootstrap set (java.sql, java.xml, etc.). Its parent is the bootstrap loader.
ClassLoader platform = ClassLoader.getPlatformClassLoader();
System.out.println(platform.getClass().getName());
// jdk.internal.loader.ClassLoaders$PlatformClassLoaderApplication (System) ClassLoader
The Application ClassLoader loads application classes from the classpath (-cp / CLASSPATH). Its parent is the Platform ClassLoader. It is the default loader for user code.
ClassLoader app = ClassLoader.getSystemClassLoader();
System.out.println(app.getClass().getName());
// jdk.internal.loader.ClassLoaders$AppClassLoaderParent-First Delegation
When loading com.example.MyService, the AppClassLoader first asks its parent (Platform), which asks Bootstrap. Only if none of the parents can load it does the child try to load it itself.
Class Identity and ClassLoaders
Two classes with the same name loaded by different ClassLoaders are considered different types. Casting between them throws ClassCastException — important in plugin systems and OSGi.
// Loaded by two different loaders → different Class objects
Class<?> c1 = loader1.loadClass("com.example.Plugin");
Class<?> c2 = loader2.loadClass("com.example.Plugin");
System.out.println(c1 == c2); // false!Writing a Custom ClassLoader
Extend ClassLoader and override findClass(String name). Read bytecode from a custom source (encrypted JAR, network, database) and call defineClass.
public class EncryptedClassLoader extends ClassLoader {
public EncryptedClassLoader(ClassLoader parent) { super(parent); }
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] bytes = decrypt(readBytecodeFromVault(name));
return defineClass(name, bytes, 0, bytes.length);
}
}URL ClassLoader: Loading from JARs
URLClassLoader loads classes from a list of URLs (file paths or HTTP URLs). Useful for plugin systems that add JARs at runtime.
URL[] urls = { new File("plugins/my-plugin.jar").toURI().toURL() };
try (URLClassLoader loader = new URLClassLoader(urls, getClass().getClassLoader())) {
Class<?> cls = loader.loadClass("com.example.PluginImpl");
Plugin plugin = (Plugin) cls.getDeclaredConstructor().newInstance();
plugin.start();
}Closing ClassLoaders
Always close URLClassLoader when done — it holds JARs open. Closing it allows the JARs to be deleted or updated. Use try-with-resources.
Child-First Delegation (Isolated Loading)
Some containers (Tomcat, Spring Boot fat JAR) invert the hierarchy: the child loader tries first, falling back to the parent only if not found. This isolates library versions between web applications.
ClassLoader Leaks
A classloader is GCed only when no class loaded by it is reachable. Static fields holding objects from a loaded class keep the loader alive — a common leak in redeploy scenarios.
Quick Check
What does a ClassLoader do before trying to load a class itself?
Recap
Three-level hierarchy: Bootstrap → Platform → Application. Parent-first delegation prevents class duplication. Custom loaders override findClass. Use URLClassLoader for plugin systems. Close loaders to prevent leaks.
Frequently asked questions
Is the “ClassLoader Hierarchy and Custom Loaders” lesson free?
Yes — the full text of “ClassLoader Hierarchy and Custom Loaders” is free to read here on the web, and the Java Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Java Academy course, upgrade to CoddyKit PRO.
What will I learn in “ClassLoader Hierarchy and Custom Loaders”?
Understand bootstrap, platform, and application class loaders and write a custom ClassLoader. You practise Java Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Java Academy?
No prior experience is required. Java Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “ClassLoader Hierarchy and Custom Loaders” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Java Academy lesson?
Yes. Every Java Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Class Loading Phases: Load, Link, Initialize
- ClassLoader Hierarchy and Custom Loaders
- Inspecting Bytecode with javap
- JIT Compilation and Tiered Compilation