Which class loaders does a modern JVM create at startup, what does each of them load, and how are they linked to one another?

## The startup trio When a JVM starts it creates a small, fixed set of loaders. They are built in, they always exist, and every class in the process is ultimately defined by one of them or by a loader someone created underneath them. **The bootstrap loader** is special because it lives inside the virtual machine itself, written in native code as part of the runtime rather than as a Java class. It defines the classes the runtime cannot function without: `java.lang.Object`, `java.lang.String`, `java.lang.Class`, the collections, and generally the contents of the core module `java.base`. Because it is native, there is no `ClassLoader` instance for it, and it has no parent, it is the root of the chain. It reads its classes from the runtime image shipped with the JDK, not from a JAR you can point at. **The platform loader** sits directly beneath it. Its job is the rest of the platform: JDK modules that are part of the specification or the JDK distribution but not the core set, such as database, XML and cryptography modules. Practically, it exists so the platform can be partitioned, some modules are always present and privileged, others are ordinary platform code. Its parent is the bootstrap loader, and it is reachable from Java code via `ClassLoader.getPlatformClassLoader()`. **The application loader**, also called the system loader, is the one your code meets. It defines classes from the **class path** and from application **modules on the module path**. Its parent is the platform loader. `ClassLoader.getSystemClassLoader()` returns it, and calling `getClassLoader()` on one of your own classes returns this object (unless a framework created a loader beneath it). ## What 'parent' actually means This is the most common misconception worth nailing down: the chain is **not** class inheritance. Each loader simply holds a reference to another loader designated as its parent. `ClassLoader` is an ordinary class; the built-in loaders are instances (except bootstrap, which has none). The chain is a runtime data structure, walkable with `getParent()` until you reach `null`, which represents the bootstrap loader. So the practical shape is: ``` application (system) loader | parent platform loader | parent bootstrap loader (represented by null) ``` Application frameworks and containers add loaders *below* the application loader, typically one per plugin, web application or deployment unit, extending the tree downward. ## Why the split into roles matters Separating the loaders is not bookkeeping; it enforces two properties. First, **trust and integrity of the core**. Because the core classes are defined by a loader nobody can substitute, application code cannot supply its own `java.lang.String` and have it used by the runtime. The core is anchored. Second, **namespaces**. A loaded type's runtime identity is the pair *(binary name, defining loader)*, not the name alone. Two loaders can each define a class called `com.acme.Widget`, and the JVM treats those as two unrelated types. This is what makes containers able to host applications with different versions of the same library in one process, and it is why the loader that defined a class is a meaningful property rather than a trivia detail. It also means the loader that *initiates* a request and the loader that ultimately *defines* the class need not be the same: `getClassLoader()` reports the defining one. ## Reading the chain in practice A few observations that come up constantly: - `String.class.getClassLoader()` returns `null`, because the bootstrap loader has no Java representation. `null` in loader APIs conventionally means bootstrap. - Your class returns the application loader; a JDK class such as one from the SQL module returns the platform loader. - Walking `getParent()` from the application loader gives platform, then `null`. - The built-in loaders in current JVMs are internal implementation types, not the general-purpose URL-based loader class some older code assumes. ## Where classes actually come from The bootstrap and platform loaders read from the runtime image built into the JDK. The application loader reads the class path (directories and JARs, in order) and the module path (application modules). Nothing in the chain is inherently tied to files: a loader is defined by its ability to produce bytes for a name, which is exactly why custom loaders can fetch from anywhere. ## The short version to say out loud Three built-in loaders, chained child-to-parent: application, platform, bootstrap. Bootstrap is native, has no parent and no Java object, and owns the core runtime. Platform owns the remaining JDK modules. Application owns your code. Each is a namespace boundary, so a class's identity includes which loader defined it.