JVM Class Loading

Classes enter the JVM through class loaders arranged in a parent-delegation tree. Bootstrap loads core JDK classes; platform and application loaders handle modules and your classpath.

Loader Hierarchy

Bootstrap: \`java.base\` classes from \`jrt:/\` or \`rt.jar\` (older JDKs)
Platform: module-layer classes
Application: classes from \`-cp\` or \`CLASSPATH\`

Delegation model: a loader asks its parent first, then searches its own path. This prevents application code from replacing \`java.lang.String\`.

Custom loaders (OSGi, Spring Boot fat jars) override \`findClass\` to load bytes from non-standard locations.

For example, loading \`com.example.App\` walks loaders until one finds \`com/example/App.class\` bytes, defines the class, and links it.

Design Notes

Breaking delegation by loading `java.lang` classes from an application loader is a security bug. Custom loaders still ask the parent for core classes before searching their own JARs.

For This Exercise

This exercise asks you to document bootstrap, platform, and application loaders and the delegation order. You will explain how \`ClassLoader.loadClass\` resolves names before your mini-JVM loads its first class.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Simulate the JVM's class loaders:

the parent-first delegation chain bootstrap ← platform ← app, plus custom loaders (including child-first ones, like servlet containers use);
per-loader caches;
superclass resolution during definition;
the rule that a runtime class is identified by (name, defining loader);
the protection of java/*;
one-time class initialization, supers first.

Print every delegation step.

Built-in loaders

bootstrap (no parent): java/lang/Object, java/lang/String (extends Object), java/util/AbstractList (extends Object), java/util/ArrayList (extends AbstractList).
platform (parent bootstrap): java/sql/Date and javax/sql/DataSource, both extending Object.
app (parent platform): its classpath is empty until provide.

Input

# starts a comment.

c
Loading…

Loading (`load(L, C)` at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

If C is in L's cache: L: cached C (defined by D), and return D.
If L is child-first, C is not java/*, and C is on L's path: L: child-first, found locally, then define.
If L has a parent: L: delegate to P, then load(P, C) at depth d+1. If that succeeds, cache C in L and return. If a definition failed, fail too.
If C is on L's path (and step 2 didn't apply): define.
Otherwise: L: not found.

Define C in L:

A java/* class defined by any loader other than bootstrap or platform fails with L: SecurityException: prohibited package name java.
Otherwise print L: define C, then (if C has a super S) L: resolve superclass S followed by load(L, S) at depth d+1. On failure, print L: NoClassDefFoundError: S and fail.
On success, cache C in L as defined by L.

Every loader that sees a successful result caches it. That makes it an initiating loader.

Output

c
Loading…

Final line: => C defined by D, => ClassNotFoundException: C or => failed to define C.
init: needs C in L's cache (else init: L has not loaded C). The state belongs to the runtime class (its defining loader's entry).
- Already done: C (D) already initialized.
- Otherwise, first initialize its superclass (as the defining loader sees it, one indent deeper), then print initialize C (defined by D).
- Lines are indented 2 spaces per level of superclass recursion, starting at 0.
same: same runtime class: C defined by D, or different runtime classes: C1@D1 vs C2@D2 (casting one to the other throws ClassCastException). It uses each loader's cache (else same: L has not loaded C).
classes: L: … lists the cache in load order, with * marking classes defined by another loader, or none.
Creation: loader prints loader NAME (parent P[, child-first]).
Errors:
- loader: NAME PARENT [child-first], loader X: already exists, loader X: too many loaders (8)
- provide: LOADER CLASS [extends SUPER]
- load: LOADER CLASS, init: LOADER CLASS
- same: LOADER CLASS LOADER CLASS
- classes: LOADER
- unknown command X

Example

Input:

c
Loading…

Output:

c
Loading…

Requirements

Implement delegation recursively, one call per loader, so the trace indentation falls out of the recursion depth.
Key the initialization state and class identity by the defining loader, not by the name.

Hidden tests cover a child-first loader shadowing an app class (and the resulting ClassCastException), java/* protection, a parent-first loader where the app's copy wins, a missing superclass, initialization across loaders, and command errors.

Your Task

Simulate the JVM's class loaders:

the parent-first delegation chain bootstrap ← platform ← app, plus custom loaders (including child-first ones, like servlet containers use);

per-loader caches;

superclass resolution during definition;

the rule that a runtime class is identified by (name, defining loader);

the protection of java/*;

one-time class initialization, supers first.

Print every delegation step.

Built-in loaders

bootstrap (no parent): java/lang/Object, java/lang/String (extends Object), java/util/AbstractList (extends Object), java/util/ArrayList (extends AbstractList).

platform (parent bootstrap): java/sql/Date and javax/sql/DataSource, both extending Object.

app (parent platform): its classpath is empty until provide.

Loading (load(L, C) at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

If C is in L's cache: L: cached C (defined by D), and return D.

If L is child-first, C is not java/*, and C is on L's path: L: child-first, found locally, then define.

If L has a parent: L: delegate to P, then load(P, C) at depth d+1. If that succeeds, cache C in L and return. If a definition failed, fail too.

If C is on L's path (and step 2 didn't apply): define.

Otherwise: L: not found.

Define C in L:

A java/* class defined by any loader other than bootstrap or platform fails with L: SecurityException: prohibited package name java.

Otherwise print L: define C, then (if C has a super S) L: resolve superclass S followed by load(L, S) at depth d+1. On failure, print L: NoClassDefFoundError: S and fail.

On success, cache C in L as defined by L.

Every loader that sees a successful result caches it. That makes it an initiating loader.

Output

Loading…

Final line: => C defined by D, => ClassNotFoundException: C or => failed to define C.

init: needs C in L's cache (else init: L has not loaded C). The state belongs to the runtime class (its defining loader's entry).

Already done: C (D) already initialized.
Otherwise, first initialize its superclass (as the defining loader sees it, one indent deeper), then print initialize C (defined by D).
Lines are indented 2 spaces per level of superclass recursion, starting at 0.

same: same runtime class: C defined by D, or different runtime classes: C1@D1 vs C2@D2 (casting one to the other throws ClassCastException). It uses each loader's cache (else same: L has not loaded C).

classes: L: … lists the cache in load order, with * marking classes defined by another loader, or none.

Creation: loader prints loader NAME (parent P[, child-first]).

Errors:

loader: NAME PARENT [child-first], loader X: already exists, loader X: too many loaders (8)
provide: LOADER CLASS [extends SUPER]
load: LOADER CLASS, init: LOADER CLASS
same: LOADER CLASS LOADER CLASS
classes: LOADER
unknown command X

Requirements

Implement delegation recursively, one call per loader, so the trace indentation falls out of the recursion depth.

Key the initialization state and class identity by the defining loader, not by the name.

Understand JVM Class Loading: Bootstrap, Platform, Application

Topic Overview

JVM Class Loading

Loader Hierarchy

Design Notes

For This Exercise

Implementation Task

Your Task

Built-in loaders

Input

Loading (`load(L, C)` at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

Output

Example

Requirements

Solve it with a plan

Progressive Hints

Resources

Learn by building

JVM Class Loading

Loader Hierarchy

Design Notes

For This Exercise

Your Task

Built-in loaders

Input

Loading (`load(L, C)` at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

Output

Example

Requirements

Understand JVM Class Loading: Bootstrap, Platform, Application

Topic Overview

JVM Class Loading

Loader Hierarchy

Design Notes

For This Exercise

Implementation Task

Your Task

Built-in loaders

Input

Loading (load(L, C) at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

Output

Example

Requirements

Solve it with a plan

Progressive Hints

Resources

Learn by building

JVM Class Loading

Loader Hierarchy

Design Notes

For This Exercise

Your Task

Built-in loaders

Input

Loading (load(L, C) at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

Output

Example

Requirements

Loading (`load(L, C)` at depth d, indenting each trace line 2·d spaces; the top level is depth 1)

Loading (`load(L, C)` at depth d, indenting each trace line 2·d spaces; the top level is depth 1)