Class Loading & Initialization

A class loader is asked for a binary name and produces the class's bytes (usually a .class file on the classpath, but any source works). The JVM parses that byte stream, loads the superclass and superinterfaces first, and creates a runtime type: internal class metadata plus a java.lang.Class object on the heap.

It first checks whether it has already loaded that name; if not, it asks its parent, which asks its own parent, all the way up to the bootstrap loader. Only if every ancestor fails does it try to find the bytes itself. Core JDK types are therefore always defined by the bootstrap loader.

No. A runtime type is identified by the pair (fully-qualified name, defining class loader). Load the same class file with two different loaders and you get two distinct, non-interchangeable types, each with its own Class object.

Extend java.lang.ClassLoader, override findClass(name): fetch the bytes yourself, then call the protected defineClass(name, bytes, 0, len), which asks the VM to parse them into a runtime Class. Leave loadClass alone so parent delegation still works.

Verification checks that the bytecode is structurally and type-safe and that the operand stack is disciplined. Preparation allocates the static fields and sets them to default zero values, not to their programmed initializers. Resolution replaces symbolic references in the constant pool with direct references, and may be done lazily.

ClassNotFoundException is a checked exception from explicit dynamic loading (Class.forName, loadClass) when the bytes cannot be found. NoClassDefFoundError is an Error: a type the compiler linked against symbolically is absent at runtime, or its initialization already failed.

Two reasons: consistency and safety. Delegating upward guarantees every core type is defined exactly once, by the highest loader that has it, so all code agrees on the same type. It also stops application code substituting its own version of a trusted core class. The JVM additionally refuses outright to define classes in java.* from a non-bootstrap loader.

The two names refer to two different run-time types, because the class was defined by two different class loaders. Confirm it by printing the class loader and identity hash of each side's Class object, and by finding the duplicate class source with -verbose:class.

It is the IncompatibleClassChangeError family under LinkageError: the runtime class no longer matches what the code was compiled against. Resolution is lazy and checked against the JAR actually on the classpath, so a version or duplicate-artifact mismatch shows up only when the member is first used.

Everything per-type is duplicated: two Class objects, two independent sets of static fields, two runs of the static initializer, and therefore two singletons. Neither side can see or affect the other's state, and objects from one are not instances of the other.

The compiler merges all static blocks and static field initializers, in source order, into one synthetic <clinit> method. It runs in the initialization phase, after linking's preparation already zeroed those statics. A class's runtime identity is its name plus its defining loader, so each loader gets its own statics and its own <clinit> run.

During preparation the field is allocated and set to 0; the value 5 is only written when the class is initialized and its static initializer runs. A compile-time constant like static final int LIMIT = 100 carries a ConstantValue attribute and is set during preparation — and javac also copies the literal into every class that reads it.

The bootstrap loader is implemented in native code inside the VM and has no Java ClassLoader instance, so loader APIs represent it as null. Your classes are defined by the application loader, a real object. Code must treat null as 'bootstrap', not as 'no loader'.

All are LinkageError subtypes. ClassFormatError: the bytes are malformed during parsing. UnsupportedClassVersionError: a well-formed file whose class-file version is newer than the JVM supports. VerifyError: bytecode fails the verifier during linking. UnsatisfiedLinkError: a native method or native library cannot be linked.

All loading funnels through ClassLoader.defineClass(name, byte[], off, len), which is the only way a byte array becomes a runtime type. The JVM never looks at the origin of those bytes, so they can come from a JAR, a network stream, a database, an encrypted blob, or a generator that builds them in memory.

Metadata lives in native memory (HotSpot Metaspace): runtime constant pool, field and method descriptors, method bytecode, inheritance links and dispatch tables. The heap holds a java.lang.Class mirror — the Java-visible handle used by reflection and .class literals, which in HotSpot also stores the class's static field values. The two reference each other.

findClass is the hook the inherited delegation algorithm calls only after every ancestor has failed, so overriding it adds a new source of bytes while preserving parent-first order. loadClass is the delegation algorithm, so overriding it replaces the policy — usually turning the loader child-first, with duplicate definitions as the risk.

Create a fresh class loader for the new version, define the new bytes there, build a new object graph, and atomically swap the reference. The old loader, its classes and all their instances are then abandoned; they are collected only when nothing references them. Live objects are not upgraded — state must be migrated explicitly.

Each class has an initialization lock and a state (uninitialized, in progress by thread T, initialized, erroneous). One thread runs the initializer while others block; recursive entry by the same thread is allowed and proceeds. Two classes initializing each other from two threads therefore deadlock, and slow initializers stall every caller.

Class files reference members symbolically — by name and descriptor in the constant pool. HotSpot resolves each reference lazily, on first execution of the instruction that uses it. The rare branch's method reference was never resolved before, so the mismatch between the compiled-against and loaded classes only surfaced when the branch finally ran.

The verifier proves structural and type safety: operand-stack depth and types agree on every path, jumps target real instructions, locals are used with consistent types, access rules hold, and objects are initialized before use. It verifies because the JVM must assume bytecode came from anywhere, not from javac.

Java 8's extension loader (lib/ext) was replaced by the platform loader, and the built-in loaders are no longer URLClassLoader instances. Casting the system loader to URLClassLoader or reflectively calling addURL fails, and code scanning rt.jar breaks because platform classes now come from the runtime image.

The host gives each deployment its own loader as a sibling under a shared parent. Because a type's identity is its name plus defining loader, each application gets a private copy of the library. Any type crossing the boundary must be defined by the common ancestor, or the two sides see incompatible types.

No. An implementation may load classes eagerly, in bulk, or from a prebuilt archive. The only requirement is that any error from loading or linking is thrown at the point where the program would first actively use the class — so early loading must stay invisible. Initialization timing, by contrast, is strictly specified.

By deliberately inverting delegation: the JDK code obtains a loader that can see application classes and loads through it. Usually that is the thread context class loader, Thread.currentThread().getContextClassLoader(), which defaults to the application loader; APIs like ServiceLoader also accept an explicit loader argument.

Because a type is (name + defining loader), each plugin loader defines its own private copy of its dependencies, so conflicting versions coexist without clashing. But every type crossing the boundary — the plugin API interfaces and any exchanged data types — must be defined once by a shared ancestor loader that all plugins delegate to.

Move the check earlier than execution: converge dependency versions centrally, fail builds on duplicate classes and convergence conflicts, gate published artifacts on binary compatibility, smoke-test the assembled runtime artifact, and isolate irreconcilable versions with shading or separate loaders.

To isolate library versions: each component gets the exact dependency versions it bundles, rather than whatever the container happens to ship. The cost is duplicate class definitions — the same name defined by several loaders — producing cast failures at boundaries, duplicated static state, and memory retained per component.

No. The JVM's run-time package is the pair (package name, defining class loader), so same-named packages in different loaders are different packages. Package-private access across them fails with IllegalAccessError, even though the source-level package names match.