Class Loaders

There are three standard loaders in a parent chain. The bootstrap loader (written in native code) loads the core JDK classes. The platform/extension loader sits beneath it, and the application/system loader — the one that loads your classpath — sits beneath that. The key mechanism is parent-delegation: when asked to load a class, a loader first asks its parent, which asks its parent, all the way up; only if no ancestor can find the class does the original loader try to load it itself. This guarantees that core classes like java.lang.String are always loaded by the bootstrap loader and can never be shadowed by a malicious class of the same name on the classpath, which is a foundational security property. Loading itself proceeds in phases — loading the bytes, linking (verify, prepare, resolve), and initialising static state.

The deeper point that interviews probe is class identity: a class's runtime identity is the pair of its fully-qualified name and the loader that loaded it. The same bytecode loaded by two different loaders produces two distinct Class objects whose instances are not assignment-compatible, which is exactly how application servers isolate deployed apps and how plugin systems sandbox modules. It is also why leaking a custom class loader leaks every class it loaded — a common cause of Metaspace exhaustion after repeated hot redeploys.