18

从 Java 8 开始,我知道类加载器的层次结构如下:

引导类加载器 → 扩展类加载器 → 应用程序类加载器

Java 9 中类加载器的层次结构发生了哪些变化,它是如何工作的?

4

2 回答 2

18

这是 Java 9 的迁移指南

新的类加载器实现

JDK 9 维护自 1.2 版本以来存在的类加载器的层次结构。但是,为了实现模块系统,进行了以下更改:

应用程序类加载器不再是 URLClassLoader 的实例,而是一个内部类。它是既不是 Java SE 也不是 JDK 模块的模块中的类的默认加载器。

扩展类加载器已重命名;它现在是平台类加载器。Java SE 平台中的所有类都保证通过平台类加载器可见。此外,在 Java Community Process 下标准化但不属于 Java SE 平台的模块中的类保证通过平台类加载器可见。

仅仅因为一个类通过平台类加载器可见并不意味着该类实际上是由平台类加载器定义的。Java SE 平台中的一些类是由平台类加载器定义的,而其他类是由引导类加载器定义的。应用程序不应依赖于哪个类加载器定义了哪个平台类。

JDK 9 中的更改可能会影响创建以 null 为父类加载器的类加载器(即引导类加载器)并假定所有平台类对父类可见的代码。可能需要更改此类代码以将平台类加载器用作父级(请参阅 ClassLoader.getPlatformClassLoader)。

平台类加载器不是 URLClassLoader 的实例,而是内部类的实例。

引导类加载器仍然内置在 Java 虚拟机中,并在 ClassLoader API 中由 null 表示。它定义了一些关键模块中的类,例如 java.base。因此,它定义的类远少于 JDK 8 中的类,因此使用 -Xbootclasspath/a 部署的应用程序或创建以 null 作为父类的类加载器的应用程序可能需要如前所述进行更改。

于 2017-09-29T17:42:36.753 回答
13

Java-9 中的ClassLoader修订说明:

Java 运行时具有以下内置类加载器:

  • Bootstrap class loader:虚拟机的内置类加载器通常表示为 null,并且没有父级。

  • Platform class loader: To allow for upgrading/overriding of modules defined to the platform class loader, and where upgraded modules read modules defined to class loaders other than the platform class loader and its ancestors, then the platform class loader may have to delegate to other class loaders, the application class loader for example. In other words, classes in named modules defined to class loaders other than the platform class loader and its ancestors may be visible to the platform class loader.

  • System class loader: It is also known as application class loader and is distinct from the platform class loader. The system class loader is typically used to define classes on the application class path, module path, and JDK-specific tools. The platform class loader is a parent or an ancestor of the system class loader that all platform classes are visible to it.

于 2017-09-29T17:47:52.570 回答