Resumen personal del sistema modular Java

1. Sistema modular Java

JDK9 comenzó a introducirse, el propósito: para poder lograr el objetivo clave de la modularización: mecanismo de aislamiento de embalaje configurable.

El mecanismo de aislamiento de embalaje configurable resuelve principalmente:

[1] Primero, debemos resolver el problema de confiabilidad de encontrar dependencias basadas en ClassPath antes de JDK9;

[2] También resuelve el problema de accesibilidad de tipo público de los archivos JAR cruzados en la ruta de clase original.

 

2. Compatibilidad del módulo

2.1 Compatibilidad con versiones anteriores del módulo

Para hacer que el mecanismo de aislamiento del paquete configurable sea compatible con el mecanismo de búsqueda de ruta de clase tradicional, JDK9 propuso el concepto de ruta de clase y ruta de módulo;

Si una biblioteca de clases es un módulo o un paquete JAR tradicional depende solo de la ruta en la que se almacena.

2.2 El sistema modular seguirá las siguientes tres reglas para garantizar que los programas Java que dependen de las dependencias de ruta de clase tradicionales puedan ejecutarse directamente en JDK9 y versiones posteriores sin modificación:

[1] Reglas de acceso a archivos JAR en la ruta de clase:

 

[2] Reglas de acceso al módulo en la ruta del módulo:

[3] Reglas de acceso a archivos JAR en la ruta del módulo:

2.2 Problemas de gestión y compatibilidad entre módulos

El sistema modular Java actualmente no admite agregar números de versión a las definiciones de módulo para administrar y restringir las dependencias, ni admite el concepto de múltiples números de versión y funciones de selección de versión.

Las capacidades de implementación y reemplazo en tiempo de ejecución de los módulos no están integradas en el sistema modular Java y la máquina virtual Java, y aún deben implementarse a través de cargadores de clases.

 

3. Cargador de clases bajo modularización

Para garantizar la compatibilidad, JDK9 no ha sacudido fundamentalmente la arquitectura del cargador de clase de tres niveles y el modelo de delegación principal que se han estado ejecutando durante 20 años desde JDK1.2.

Sin embargo, para la implementación sin problemas del sistema modular, el cargador de clases bajo modularización ha sufrido algunos cambios que deben tenerse en cuenta:

[1] Primero, el cargador de clase de extensión se reemplaza por el cargador de clase de plataforma. Naturalmente, no es necesario mantener el directorio <JAVA_HOME> \ lib \ ext.

【2】 BuiltinClassLoader。

La estructura de herencia del cargador de clases antes de JDK9:

La estructura del cargador de clases de JDK9 y posterior:

JDK9 y posterior relación de delegación del cargador de clases:

El sistema de módulos Java estipula claramente que los cargadores de tres clases son responsables de los respectivos módulos cargados, a saber: la relación de atribución mencionada anteriormente.

 

162 artículos originales publicados · ganó 30 · 90,000 vistas +

Supongo que te gusta

Origin blog.csdn.net/ScorpC/article/details/105651300
Recomendado
Clasificación