How did the JVM's built-in class loaders change when Java 9 introduced the module system, compared with Java 8, and what kinds of existing code commonly break as a result?

## The Java 8 arrangement Before modules, a JVM had three loaders: bootstrap (native, loading `rt.jar` and friends from `lib`), the **extension** loader (`sun.misc.Launcher$ExtClassLoader`, loading anything in `lib/ext` or the directories named by `java.ext.dirs`), and the **application** loader (`sun.misc.Launcher$AppClassLoader`, loading the class path). Both non-bootstrap loaders were `URLClassLoader` subclasses, which meant they exposed a list of URLs and a protected `addURL` method. That detail leaked into an enormous amount of tooling. Two idioms in particular became folklore: casting `ClassLoader.getSystemClassLoader()` to `URLClassLoader` to *read* the effective classpath, and reflectively calling `addURL` to *append* to the classpath at runtime, used by hot-reloaders, test harnesses, script engines and build tools. ## What Java 9 changed **The extension loader is gone.** It was replaced by the **platform class loader**, obtained with `ClassLoader.getPlatformClassLoader()`. Its purpose is different: rather than loading arbitrary extension JARs, it defines JDK platform modules that are not in the core set. The endorsed-standards and extension mechanisms were removed, so the old "install a JAR into the JDK to override a platform API" trick no longer exists. The upgradeable-module path replaced part of that need for a narrow set of modules. **Loader identity changed.** The built-in loaders are now internal implementation classes designed around modules. Crucially, they are **not** `URLClassLoader` instances. The consequences are direct: - `((URLClassLoader) ClassLoader.getSystemClassLoader()).getURLs()` throws `ClassCastException`. - The reflective `addURL` hack fails: there is no such method to reach, and from Java 16 the default denial of illegal reflective access blocks equivalent tricks against JDK internals anyway. - Libraries that discovered the classpath through the loader had to switch to reading the `java.class.path` system property, or to a supported mechanism such as accepting an explicit loader or building their own `URLClassLoader` for extra locations. **Where platform classes live changed.** `rt.jar` and `tools.jar` no longer exist; the runtime ships as a packaged image. Anything that enumerated `rt.jar` to list JDK classes (old scanners, coverage tools, some obfuscators) stopped working. The supported replacements are the module APIs and, for tools, the JRT filesystem view. **Loader assignment for some JDK classes changed.** With the platform split, classes previously defined by the bootstrap loader may now be defined by the platform loader. Code that tested `SomeJdkClass.class.getClassLoader() == null` as a proxy for "is a JDK class" gives wrong answers; the module-aware check is to look at the class's `Module` instead. **Boot class path options changed.** The old `-Xbootclasspath` (full replacement) and `-Xbootclasspath/p` (prepend) were removed; only `-Xbootclasspath/a` (append) remains. Overriding platform classes is intentionally hard now, with `--patch-module` as the supported and narrower alternative. ## The typical breakage list In migration work, the recurring failures are: 1. `ClassCastException` casting the system loader to `URLClassLoader`, usually deep inside a build tool, an application server, or a testing library. 2. Runtime classpath augmentation via reflective `addURL` silently unavailable, so dynamic plugin loading has to be redesigned around a purpose-built loader. 3. Class scanners that walked `rt.jar` finding zero platform classes. 4. Code relying on `lib/ext` to inject an implementation of a platform API. 5. Assumptions that any class with a `null` loader is a JDK class, or that every JDK class has a `null` loader. 6. From Java 16 onward, `setAccessible` on JDK internals throwing `InaccessibleObjectException` unless opened explicitly with `--add-opens`, which turned several of the above workarounds from "deprecated but functioning" into hard failures. ## The migration posture The healthy pattern is to stop treating built-in loaders as configurable containers. If you need extra code locations at runtime, construct **your own** loader (a `URLClassLoader` with an explicit parent is still perfectly supported) rather than mutating a built-in one. If you need to know the classpath, read the property. If you need to enumerate platform classes, use module APIs. If you need to override platform behaviour, use the supported module options rather than the deleted extension mechanism. The underlying theme is that Java 9 turned the loader hierarchy from an implicitly extensible structure into a defined, encapsulated one. The three roles remained, application over platform over bootstrap, but the middle role was redefined and the implementation stopped being something applications may reach into.