Understand JVM Class Loading: Bootstrap, Platform, Application

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.