Bootstrap Class Loader

The bootstrap class loader loads foundational Java runtime classes needed by the JVM. It is implemented as part of the JVM runtime rather than as an ordinary Java class.

The bootstrap class loader is the starting point of Java's class-loading mechanism. It is responsible for loading core runtime classes, such as classes in `java.lang`, that the JVM needs to execute Java programs safely and correctly.

Unlike application-defined class loaders, the bootstrap class loader is not an ordinary Java object that you instantiate or manipulate like a normal `ClassLoader`. Its implementation is associated with the JVM and the underlying runtime environment.

Java uses a hierarchy of class loaders. When a class needs to be loaded, delegation normally proceeds toward a parent loader first. The bootstrap loader sits at the top of this hierarchy, above the platform and application class loaders.

A useful consequence is that core runtime classes are separated from application classes. For example, an application cannot simply provide its own `java.lang.String` and have the normal class-loading process replace the platform's core `String` class.

In modern Java, the exact organization of runtime classes depends on the Java version and module system. For interview purposes, remember the bootstrap loader as the JVM-level loader responsible for foundational runtime classes.

Key points

Interview questions

What is the bootstrap class loader in Java?

The bootstrap class loader is the JVM's built-in mechanism for loading foundational Java runtime classes. It is not implemented as an ordinary Java `ClassLoader` instance. It is the root of the standard class-loader hierarchy. Classes such as `java.lang.String` are associated with it.

Why does `String.class.getClassLoader()` return `null`?

`String` is a foundational runtime class associated with the bootstrap class loader. The bootstrap loader is not represented as a normal Java `ClassLoader` object exposed through the usual API. Therefore, `Class.getClassLoader()` uses `null` to represent that loader. This does not mean that `String` was never loaded.

Where does the bootstrap class loader fit in class-loader delegation?

The bootstrap class loader is the root of the standard delegation hierarchy. A normal class-loading request can be delegated upward toward parent loaders before a child loader attempts to define the class itself. This arrangement allows foundational classes to be resolved by trusted parent loaders first. It also reduces the chance that application classes shadow core runtime classes.

Can an application replace `java.lang.String` with its own implementation using the normal class path?

Normally, an application cannot replace the standard `java.lang.String` simply by putting another class with that name on its application class path. Class loading follows the delegation model, so the request for the core class is handled by the parent side of the hierarchy. The JVM also imposes additional restrictions around defining classes in platform-owned namespaces. The exact restrictions depend on the Java version and runtime.

How would you explain the bootstrap, platform, and application class loaders together?

They form the conventional hierarchy used by the Java runtime for loading classes. The bootstrap loader is the JVM-level root responsible for foundational runtime classes, the platform loader handles platform-level classes not supplied by the bootstrap loader, and the application loader typically handles application classes. A request generally follows parent delegation before a child loader attempts to define the class. The details of the hierarchy and class locations vary with the Java version and its module system.