Java Modular System Personal Summary

1. Java Modular System

JDK9 began to be introduced, the purpose: in order to be able to achieve the key goal of modularization: configurable packaging isolation mechanism.

The configurable packaging isolation mechanism mainly solves:

[1] First, we must solve the reliability problem of finding dependencies based on ClassPath before JDK9;

[2] It also solves the public type accessibility problem of cross-JAR files on the original class path.

 

2. Module compatibility

2.1 Backward compatibility of the module

In order to make the configurable package isolation mechanism compatible with the traditional class path search mechanism, JDK9 proposed the concept of class path and module path;

Whether a class library is a module or a traditional JAR package depends only on which path it is stored in.

2.2 The modular system will follow the following three rules to ensure that Java programs that rely on traditional class path dependencies can run directly in JDK9 and later versions without modification:

[1] JAR file access rules in the class path:

 

[2] Module access rules in the module path:

[3] JAR file access rules in the module path:

2.2 Management and compatibility issues between modules

The Java modular system currently does not support adding version numbers to module definitions to manage and constrain dependencies, nor does it itself support the concept of multiple version numbers and version selection functions.

The runtime deployment and replacement capabilities of modules are not built into the Java modular system and the Java virtual machine, and must still be implemented through class loaders.

 

3. Class loader under modularization

In order to ensure compatibility, JDK9 has not fundamentally shaken the three-tier class loader architecture and parent delegation model that have been running for 20 years since JDK1.2.

However, for the smooth implementation of the modular system, the class loader under modularization has undergone some changes that should be noted:

[1] First, the extension class loader is replaced by the platform class loader. Naturally, there is no need to keep the <JAVA_HOME> \ lib \ ext directory.

【2】BuiltinClassLoader。

The class loader inheritance structure before JDK9:

The structure of the class loader of JDK9 and later:

JDK9 and later class loader delegation relationship:

The Java module system clearly stipulates that the three class loaders are responsible for the respective modules loaded, namely: the attribution relationship mentioned above.

 

Published 162 original articles · won 30 · 90,000 views +

Guess you like

Origin blog.csdn.net/ScorpC/article/details/105651300