A finishing touch

The JVM supports two types of class loaders: Bootstrap ClassLoader and User-Defined ClassLoader.

Conceptually, a custom class loader generally refers to a class loader defined by developers in a program, but the Java virtual machine specification does not define it. Instead, all class loaders derived from the abstract class ClassLoader are divided into custom class loaders. No matter how the types of class loaders are divided, the most common class loader structures in the program are as follows:

• Except for the top-level startup class loader, all other class loaders should have their own "parent class" loader.

• Different class loaders seem to be Inheritance relationships, but they are actually inclusion relationships. The lower loader contains the references of the upper loader.

The relationship between parent class loader and child class loader is as follows:

class ClassLoader {
    ClassLoader parent;//Parent class loader

    public ClassLoader(ClassLoader parent) {
        this.parent = parent;
    }
}

class ParentClassLoader extends ClassLoader {
    public ParentClassLoader(ClassLoader parent) {
        super(parent);
    }
}

class ChildClassLoader extends ClassLoader {
    public ChildClassLoader(ClassLoader parent) { //parent = new ParentClassLoader();
        super(parent);
    }
}

Because the subclass loader contains the reference of the parent class loader, you can obtain the corresponding parent class loader through the subclass loader method.

be careful

The startup class loader is written in C/C + + language, while the custom class loader is written in Java language. Although the extension class loader and application class loader are written in Java language by jdk developers, they are also written in Java language, so they are also called custom class loader.

Class II boot loader

1. Description

Boot classloader (boot classloader, Bootstrap ClassLoader)

• This class load is implemented in C/C + + language and nested inside the JVM.

• It is used to load the core library of Java (contents in JAVAHOME/jre/lib/rt.jar or sun.boot.class.path path). It is used to provide classes required by the JVM itself.

• Does not inherit from Java Lang. classloader, no parent loader.

• For security reasons, the Bootstrap startup class loader only loads classes with package names beginning with java, javax, sun, etc

• Load extension classes and application class loaders and specify them as their parent class loaders.

• Use the - XX:+TraceClassLoading parameter to get.

The startup class loader is written in C + +.

• C/C + +: pointer function & function pointer, C + + supports multiple inheritance and is more efficient

• Java: evolved from C + + (c + +) – version, single inheritance

2 code

package chapter04.java;

import java.net.URL;

/**
* Loader test
*/
public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println("**********Start class loader**************");
        // Get the path of the api that bootstrap classloader can load
        URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL element : urLs) {
            System.out.println(element.toExternalForm());
        }
        // Select a class randomly from the above path to see what its classloader is: boot classloader
        ClassLoader classLoader = java.security.Provider.class.getClassLoader();
        System.out.println(classLoader);// null boot class loader is not available
    }
}

3 execution results

**********Start class loader**************
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/resources.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/rt.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/sunrsasign.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/jsse.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/jce.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/charsets.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/lib/jfr.jar
file:/D:/ProgramFiles/Java/jdk1.8.0_251/jre/classes
null

Three extended class loader

1. Description

Extension ClassLoader

• Written in Java language by sun misc. Launcher $extclassloader implementation.

• Inherited from ClassLoader class

• The parent class loader is the boot class loader

From Java Load the class library in the directory specified by the ext.dirs system attribute, or load the class library from the jre/lib/ext subdirectory of the JDK installation directory. If the JAR created by the user is placed in this directory, it will also be automatically loaded by the extension class loader.

2 code

package chapter04.java;

import java.net.URL;

/**
* Loader test
*/
public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println("***********Extension classloader load path*************");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")) {
            System.out.println(path);
        }

        // Select a class randomly from the above path to see what its classloader is: extended classloader
        ClassLoader classLoader1 = sun.security.ec.CurveDB.class.getClassLoader();
        System.out.println(classLoader1); // sun.misc.Launcher$ExtClassLoader@1540e19d
    }
}

3 execution results

***********Extension classloader load path*************
D:\ProgramFiles\Java\jdk1.8.0_251\jre\lib\ext
C:\WINDOWS\Sun\Java\lib\ext
sun.misc.Launcher$ExtClassLoader@5cad8086


Process finished with exit code 0

Class IV system loader

Application class loader (system class loader, AppClassLoader)

• java language, written by sun misc. Launcher $appclassloader implementation

• Inherited from ClassLoader class

• The parent class loader is an extension class loader

• It is responsible for loading the environment variable classpath or the system attribute Java class. Path specifies the class library under the path

• The class loader in the application defaults to the system class loader.

• It is the default parent loader for user-defined class loaders

• The ClassLoader can be obtained through the getSystemClassLoader() method of ClassLoader

V. user defined class loader

User defined class loader

• In the daily application development of Java, class loading is almost performed by the above three kinds of loaders. If necessary, we can also customize the class loader to customize the loading method of the class.

• One of the key factors reflecting the strong vitality and charm of the Java language is that Java developers can customize the class loader to realize the dynamic loading of the class library. The loading source can be a local JAR package or a remote resource on the network.

• A very excellent plug-in mechanism can be realized through class loader, and there are many practical application cases in this regard. For example, the famous OSGI component framework, such as Eclipse's plug-in mechanism. Class loader provides a mechanism for applications to dynamically add new functions, which can be implemented without repackaging and publishing applications.

• At the same time, custom loaders can realize application isolation. For example, middleware and component frameworks such as Tomcat and Spring implement custom loaders internally and isolate different component modules through custom loaders. This mechanism is much better than C/C + + programs. It is almost impossible to add new functions without modifying C/C + + programs. Only one compatibility can block all good ideas.

• Custom class loaders usually need to inherit from ClassLoader.