Why does calling getClassLoader() on java.lang.String's Class object return null, while calling it on one of your own application classes returns a real object, and what does that null mean for code that uses the returned loader?

## Where the null comes from Every loaded type records the loader that **defined** it, and `Class.getClassLoader()` reports that loader. For nearly all classes that is an ordinary Java object. For the core runtime classes it is not, because the loader that defines them is not a Java object at all. The bootstrap loader is part of the virtual machine implementation, written in native code. It has to be: it defines `java.lang.Object`, `java.lang.Class` and `java.lang.ClassLoader` themselves, so it cannot be written as a Java class that depends on those types already existing. Since there is no instance to hand back, the platform chose a sentinel, and the sentinel is `null`. That convention is used consistently: - `String.class.getClassLoader()` -> `null` - `ClassLoader.getPlatformClassLoader().getParent()` -> `null`, which is how you recognise the top of the parent chain - passing `null` as the loader argument to APIs such as `Class.forName(String, boolean, ClassLoader)` means "start from the bootstrap loader" Meanwhile your own classes are defined by the application loader, which is a real object with a real parent, so you get a reference. ## Null means 'bootstrap', not 'absent' This is the practical heart of the question. In loader APIs, `null` is a meaningful value denoting a specific loader, exactly like a real reference. It is not an error signal and it does not mean the class has no loader. This regularly bites library code. A common idiom is: ```java URL cfg = someClass.getClassLoader().getResource("config.properties"); ``` That works for application classes and throws `NullPointerException` the moment `someClass` happens to be a JDK core class, which is easy when the class is derived from user input, from a stack walk, or from a generic utility that accepts any `Class`. The same trap appears in reflection helpers, serialization frameworks and dependency-injection containers that resolve loaders dynamically. ## Safe patterns There are three reliable approaches. **Pass it through.** APIs designed for loaders accept `null` and interpret it as bootstrap. `Class.forName(name, initialize, null)` and `ClassLoader`'s protected methods behave correctly. If you are only forwarding the value, do not "fix" it. **Substitute a sensible non-null loader.** If you need a loader object, for example to build a proxy or scan resources, fall back explicitly: ```java ClassLoader cl = clazz.getClassLoader(); if (cl == null) cl = ClassLoader.getSystemClassLoader(); // or getPlatformClassLoader() ``` Which fallback is right depends on intent. `getSystemClassLoader()` gives the application loader, appropriate when you want to see application resources. `getPlatformClassLoader()` gives a non-null loader whose visibility is limited to platform classes, appropriate when you deliberately do *not* want application classes in scope, for instance when isolating a service lookup. **Use the static resource helpers.** `ClassLoader.getSystemResource(...)` and `getSystemResourceAsStream(...)` are static and internally cover the bootstrap case, so they never require you to dereference a possibly-null loader. ## Why the JDK did not just invent a stub object One could imagine giving the bootstrap loader a placeholder `ClassLoader` instance. The reason not to is bootstrapping order and integrity. Constructing any Java object requires classes that the bootstrap loader itself must define first, so the stub would have to exist before the mechanism that creates it. Beyond that, exposing a real object for the core loader would hand application code a handle to the most privileged loader in the process; keeping it unrepresentable removes a whole category of manipulation. ## Related identity points A few details that make the picture complete: - The value reported is the **defining** loader, the one that actually produced the class, which is not necessarily the loader you asked. If your application loader delegates a request upward and the platform loader defines the class, `getClassLoader()` shows the platform loader. - Array classes report the loader of their element type; `int[].class.getClassLoader()` is `null` because the primitive component has no user-defined loader. - Primitive type objects such as `int.class` also return `null`. ## The one-line answer `null` is the bootstrap loader. It is native, it has no Java instance, and every loader-returning API uses `null` to say so. Treat it as a valid loader value and either forward it or substitute a deliberate fallback, never assume the returned loader is non-null.