Why does the JVM have each class loader consult its parent before searching its own sources, rather than letting each one search locally first? Concretely, what would go wrong if a loader searched locally first — for instance if an application JAR contained a class named java.lang.String?

## Runtime type identity is not just the name The fact that surprises people first: in the JVM, a type is identified by **its fully-qualified name plus the loader that defined it** — the *runtime package* / defining-loader pair. Two `Class` objects with identical names loaded by different loaders are two different types. The JVM will not silently unify them; assigning one to a variable of the other produces a `ClassCastException` whose message names the same class twice, which is one of the most confusing errors a Java developer can meet. Everything about delegation follows from this. If types are identified by (name, loader), then getting everyone to agree on shared types requires getting everyone to use the *same loader* for them. Parent-first delegation is exactly the rule that achieves it: because every loader asks upward before searching, whichever loader is highest in the chain and can supply a type always defines it, and every descendant sees that one definition. ## What consistency buys you concretely Imagine a process with a container loader and two plugin loaders beneath it. Both plugins use `java.util.List`. With parent-first delegation, all three loaders resolve it to the bootstrap loader's definition, so a plugin can hand a `List` to the container or to the other plugin and it just works. Without it, each plugin could define its own `java.util.List` from its own bundled copy, and passing a list across a boundary would fail at runtime with a nonsensical cast error. The whole idea of a shared API between components depends on the shared types being *literally* shared. This also matters for correctness of things the VM itself does. Type checks in the verifier, `instanceof`, array covariance, exception catching by type — all compare loader-qualified types. `catch (IOException e)` catches only the `IOException` your code was linked against; a differently-loaded `IOException` sails straight past. ## What safety buys you concretely Now the security half. Suppose delegation were child-first and a JAR on the application class path contained `java/lang/String.class` with an added method that copied every constructed string to a network socket. The application loader would find and define it locally, and from that moment every string in that loader's world would be attacker-controlled — including strings used for permission checks, file paths, and SQL. The same trick against `java.lang.SecurityManager`, `java.lang.ClassLoader` itself, or `java.security.*` would let untrusted code define the very machinery meant to constrain it. Parent-first delegation removes the possibility for the built-in loaders: the bootstrap loader is asked first, it has `java.lang.String`, and its answer is final. Your file is never even opened. ## The independent second check Delegation alone would be a fragile defence, because delegation is *policy implemented in Java code* — anyone can subclass `ClassLoader` and override `loadClass` to search locally first. So the platform does not rely on it alone: - **Prohibited package names.** `ClassLoader.defineClass` refuses to define any class whose name begins with `java.` unless the caller is the bootstrap loader, throwing `SecurityException: Prohibited package name: java.lang`. This is enforced in the platform, not by convention, so breaking delegation still cannot get you a custom `java.lang.String`. - **Package sealing.** A JAR can declare a package sealed, meaning all classes in that package must come from that same JAR — preventing an attacker from injecting a new class *into* a trusted package to gain package-private access. - **Module encapsulation.** In modern JDKs the module system adds strong encapsulation: packages are exported explicitly, split packages across modules are rejected, and the runtime image's contents cannot be shadowed by a class path entry. A strong answer names delegation as the primary mechanism *and* knows that the platform has a hard check behind it. ## The nuance that separates a good answer Delegation protects the *core platform* absolutely, but it does not protect *your* classes from being shadowed by a loader that inverts the order. A container that deliberately runs child-first for application packages is making a considered trade — isolation of library versions in exchange for the risk of duplicate definitions. That is a legitimate design, and the protection that survives it is the `java.*` defineClass check, not delegation. ## How to answer in an interview "Two reasons. Consistency: type identity is name plus defining loader, so delegating upward makes sure a shared type has exactly one definition and components can pass instances across boundaries. Security: user code cannot substitute a core class, because the bootstrap loader answers first. And even if someone overrides `loadClass` to break delegation, `defineClass` still refuses any `java.*` name from a non-bootstrap loader."