An in-depth understanding of the Java Virtual Machine (XI) — class loaders

Class loader

In the loading phase of the class loading process, one of the tasks is to obtain the binary byte stream of the class by its fully qualified name. The virtual machine specification does not restrict the source of the binary byte stream, so the class loader is used to load the byte stream through the specified path.

The uniqueness of any Class is determined by the Class loader and the Class itself. That is to say, even if two classes are loaded from the same Class file and both are loaded by the same virtual machine, as long as the Class loader is different, the two classes must be different.

The type of class loader

From the perspective of Java virtual machines, class loaders are divided into two types. One is BootstrapClassLoader, which is written in C++ language and belongs to a part of virtual machines. The other is any loader other than the launcher ClassLoader, which is written in the Java language, independent of the virtual machine, and all inherits from the abstract java.lang.classloader class.

From a Java developer’s point of view, there are three types of class loaders: It is responsible for the class libraries in the JAVA_HOME/lib directory and cannot be directly referenced by Java programs. When we need to delegate the class loader to load the class, we can use NULL instead.

The Extension ClassLoader is responsible for loading the class libraries in the JAVAHOME/lib/ext directory, which can be directly referenced by the program.

● Application ClassLoader: Is responsible for loading the class library specified on the user’s CLASSPATH. It can be directly referenced by the program. In addition, the application loader is the default class loader if the application has not customized a direct class loader.

Parental delegation model

Understanding the parental delegation model

● The parent delegate model requires that all class loaders have their own parent class loaders except the top-level Bootstrap ClassLoader. Here the father-child relationship is realized not by inheritance but by combination. ● The parent delegate pattern is not a mandatory constraint pattern, but rather a recommended classloader model.

How the parental delegation model works

When a class loader I received the request of the class is loaded, it won’t immediately try to load the class, but to the parent class loader for the class – this class, and the superclass (or each class loader hierarchy), too, until the class loading to be assigned to the top class boot loader, only when the parent class loader feedback itself unable to load the class, Subclasses will try to load the class themselves.

Benefits of using the parent delegate model

Java classes come with a hierarchy of priorities along with class loaders. For the java.lang. Object class, for example, no matter which loader is used to load it, the loading request will eventually be delegated to the starting class loader. According to the determination principle of class uniqueness, the program will have only one Java.lang.Object class. Without the parental delegation model, the system would have two different Object classes, assuming that the user stored the java.lang. Object class in the CLASSPATH, which could lead to confusing coding.