Migración a módulos

Pocos proyectos adoptan los módulos desde el primer día. JPMS se diseñó para una migración gradual, permitiendo que el classpath y la ruta de módulos coexistan.

Las claves son los módulos automáticos y el módulo sin nombre.

Todo lo que se carga desde el classpath vive en el único módulo sin nombre. Este lee todos los demás módulos y exporta todos sus paquetes.

Es el puente que mantiene funcionando el código antiguo basado en el classpath.

Una regla fundamental: un módulo con nombre explícito no puede depender del módulo sin nombre. No puede escribir requires para código del classpath.

Por eso debe migrar de abajo arriba: convierta primero la representación de las dependencias.

Coloque un JAR normal (no modular) en la ruta de módulos y se convertirá en un módulo automático. Obtendrá un nombre derivado automáticamente, leerá todos los demás módulos y exportará todos sus paquetes.

Esto permite que los módulos con nombre declaren requires para un JAR que todavía no tiene module-info.

El nombre de un módulo automático se deriva siguiendo este orden de preferencia:

• La entrada Automatic-Module-Name del manifiesto del JAR, si está presente
• De lo contrario, del nombre del archivo JAR (sin la versión y con los guiones convertidos en puntos)

Los autores de bibliotecas deberían añadir Automatic-Module-Name a su manifiesto antes de modularizar por completo. Así garantizan un nombre de módulo estable, de modo que las cláusulas requires posteriores sigan funcionando cuando llegue el module-info real.

El enfoque recomendado para su propia aplicación es:

• Mantener las dependencias como módulos automáticos en la ruta de módulos
• Añadir primero un module-info.java a su módulo superior
• Declarar requires para los nombres de esos módulos automáticos

Suponga que guava-32.jar se encuentra en la ruta de módulos como el módulo automático com.google.common. El módulo de su aplicación ya puede declararlo mediante requires.

El sistema de módulos prohíbe que dos módulos contengan el mismo paquete. Las bibliotecas antiguas que dividen un paquete entre varios JAR provocan errores.

Puede solucionarlo fusionando los JAR, usando --patch-module o actualizando a versiones que resuelvan la división.

Los frameworks que realizan reflexión profunda pueden fallar con InaccessibleObjectException una vez que modularice el código. Añada directivas opens o, como puente temporal, la opción de lanzamiento --add-opens.

La herramienta jdeps analiza sus JAR, informa de las dependencias, detecta usos de API internas del JDK y puede incluso generar un module-info.java candidato mediante jdeps --generate-module-info.

Ejecute esta herramienta primero para planificar la migración.

Recuerde cómo obtiene un JAR normal su identidad de módulo.

Ha aprendido técnicas de migración:

• El código del classpath vive en el módulo sin nombre; los módulos con nombre no pueden declararlo mediante requires
• Los JAR normales situados en la ruta de módulos se convierten en módulos automáticos
• Establezca Automatic-Module-Name para obtener nombres estables
• Preste atención a los paquetes divididos y al acceso mediante reflexión; use jdeps para planificar

Con esto finaliza el curso de JPMS.