从Java-8开始，我知道类加载器的层次结构如下： -
Bootstrap类加载器 - >扩展类加载器 - >应用程序类加载器
Java 9中类加载器层次结构的变化是什么？它是如何工作的？
在Java-9中修订的ClassLoader指出：
Java运行时具有以下内置类加载器：
Bootstrap class loader：虚拟机的内置类加载器通常表示为null，并且没有父级。Platform class loader：为了允许升级/覆盖定义到平台类加载器的模块，并且升级后的模块读取定义到除平台类加载器及其祖先之外的类加载器的模块，那么平台类加载器可能必须委托给其他类加载器，例如，应用程序类加载器。换句话说，平台类加载器可以看到定义到除平台类加载器及其祖先之外的类加载器的命名模块中的类。System class loader：它也被称为应用程序类加载器，与平台类加载器不同。系统类加载器通常用于在应用程序类路径，模块路径和JDK特定工具上定义类。平台类加载器是系统类加载器的父级或祖先，所有平台类都是可见的。
这是Java 9的migration guide，
New Class Loader Implementations
JDK 9维护自1.2版本以来存在的类加载器的层次结构。但是，已经进行了以下更改以实现模块系统：
应用程序类加载器不再是URLClassLoader的实例，而是内部类的实例。它是模块中类的默认加载器，既不是Java SE也不是JDK模块。
扩展类加载器已重命名;它现在是平台类加载器。通过平台类加载器可以保证Java SE平台中的所有类都可见。此外，通过平台类加载器可以保证在Java Community Process下标准化但不属于Java SE Platform的模块中的类。
仅仅因为通过平台类加载器可见类并不意味着该类实际上是由平台类加载器定义的。 Java SE平台中的某些类由平台类加载器定义，而其他类则由引导类加载器定义。应用程序不应该依赖于哪个类加载器定义哪个平台类。
JDK 9中的更改可能会影响使用null创建类加载器的代码（即引导类加载器）作为父类加载器，并假定所有平台类对父级是可见的。可能需要更改此类代码以使用平台类加载器作为父代（请参阅ClassLoader.getPlatformClassLoader）。
平台类加载器不是URLClassLoader的实例，而是内部类的实例。
引导类加载器仍然内置于Java虚拟机，并在ClassLoader API中由null表示。它定义了一些关键模块中的类，例如java.base。因此，它定义的类比JDK 8中的类少得多，因此使用-Xbootclasspath / a部署的应用程序或使用null作为父级创建类加载器的应用程序可能需要如前所述进行更改。