Classloaders hierarchy in Java 9

As of Java 8, I know the hierarchy of the classloaders has been as follows:

Bootstrap classloader → Extension classloader → Application classloader

What is the change in the hierarchy of classloaders in Java 9 and how does it work?

Solution 1:

Here is the migration guide for Java 9,

New Class Loader Implementations

JDK 9 maintains the hierarchy of class loaders that existed since the 1.2 release. However, the following changes have been made to implement the module system:

The application class loader is no longer an instance of URLClassLoader but, rather, of an internal class. It is the default loader for classes in modules that are neither Java SE nor JDK modules.

The extension class loader has been renamed; it is now the platform class loader. All classes in the Java SE Platform are guaranteed to be visible through the platform class loader. In addition, the classes in modules that are standardized under the Java Community Process but not part of the Java SE Platform are guaranteed to be visible through the platform class loader.

Just because a class is visible through the platform class loader does not mean the class is actually defined by the platform class loader. Some classes in the Java SE Platform are defined by the platform class loader while others are defined by the bootstrap class loader. Applications should not depend on which class loader defines which platform class.

The changes in JDK 9 may impact code that creates class loaders with null (that is, the bootstrap class loader) as the parent class loader and assumes that all platform classes are visible to the parent. Such code may need to be changed to use the platform class loader as the parent (see ClassLoader.getPlatformClassLoader).

The platform class loader is not an instance of URLClassLoader, but, rather, of an internal class.

The bootstrap class loader is still built-in to the Java Virtual Machine and represented by null in the ClassLoader API. It defines the classes in a handful of critical modules, such as java.base. As a result, it defines far fewer classes than in JDK 8, so applications that are deployed with -Xbootclasspath/a or that create class loaders with null as the parent may need to change as described previously.

Solution 2:

The ClassLoader as revised in Java-9 states that:

The Java run-time has the following built-in class loaders:

• Bootstrap class loader: The virtual machine's built-in class loader typically represented as null, and does not have a parent.

• 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.