El Java Platform Module System [1] especifica un formato de distribución para colecciones de código Java y recursos asociados. También especifica un repositorio para almacenar estas colecciones, o módulos , e identifica cómo se pueden descubrir, cargar y verificar su integridad. Incluye características como espacios de nombres con el objetivo de corregir algunas de las deficiencias en el formato JAR existente , especialmente el JAR Hell , que puede generar problemas como classpath y problemas de carga de clases.
El Java Module System se estaba desarrollando inicialmente bajo el Java Community Process como JSR 277 y estaba programado para su lanzamiento con Java 7.
JSR 277 más tarde se puso en espera y se creó Project Jigsaw [2] para modularizar el JDK. Este JSR fue reemplazado por JSR 376 (Java Platform Module System).
Project Jigsaw se diseñó originalmente para Java 7 (2011), pero se aplazó a Java 8 (2014) como parte del Plan B, [3] y nuevamente se aplazó a una versión de Java 9 en 2017. [4] Java 9, incluido el Java Module System fue puesto en libertad el 21 de septiembre de 2017 [5].
Arquitectura
El Java Module System implementado en Java 9 incluye los siguientes JEP y JSR (solicitud de especificación de Java) : [2]
- JEP 200: El JDK modular: Defina una estructura modular para el JDK
- JEP 201: Código fuente modular: reorganice el código fuente JDK en módulos, mejore el sistema de compilación para compilar módulos y haga cumplir los límites de los módulos en el momento de la compilación
- JEP 220: Imágenes modulares en tiempo de ejecución: reestructura las imágenes en tiempo de ejecución de JDK y JRE para acomodar módulos y mejorar el rendimiento, la seguridad y la capacidad de mantenimiento
- JEP 261: Sistema de módulos: Implementar el sistema de módulos de la plataforma Java
- JEP 282: Java Linker: Cree una herramienta que pueda ensamblar y optimizar un conjunto de módulos y sus dependencias en una imagen personalizada en tiempo de ejecución [6]
- JSR 376: Sistema de módulo de plataforma Java [7]
Además, se han agregado varias otras características de JDK 9 para facilitar la transición al sistema de módulos:
- JEP 238: Archivos JAR de versiones múltiples: amplíe el formato de archivo JAR para permitir que varias versiones de archivos de clase específicas de Java coexistan en un solo archivo. [8]
- JEP 253: Preparar controles de interfaz de usuario de JavaFX y API de CSS para la modularización: definir API públicas para las funcionalidades de JavaFX que actualmente solo están disponibles a través de API internas y se volverían inaccesibles debido a la modularización. [9]
- JEP 260: Encapsular la mayoría de las API internas: haga que la mayoría de las API internas del JDK sean inaccesibles de forma predeterminada, pero deje accesibles algunas API internas críticas y ampliamente utilizadas, hasta que existan reemplazos compatibles para todas o la mayoría de sus funciones. [10]
- JEP 275: Empaquetado de aplicaciones Java modular: El empaquetador Java evolucionará para JDK 9, haciéndolo consciente de los módulos, permitiendo por ejemplo empaquetar un módulo y todos los módulos de los que depende. [11]
Propiedades de los módulos
Los módulos son una nueva forma de agrupar código. A diferencia de los archivos Jar , los módulos declaran explícitamente de qué módulos dependen y qué paquetes exportan. [12] Las declaraciones de dependencia explícitas mejoran la integridad del código, al facilitar el razonamiento sobre aplicaciones grandes y las dependencias entre componentes de software.
Por ejemplo, la siguiente declaración de módulo declara que el módulo com.foo.bar depende de otro módulo com.foo.baz y exporta los siguientes paquetes: com.foo.bar.alpha y com.foo.bar.beta :
módulo com.foo.bar { requiere com.foo.baz; exporta com.foo.bar.alpha; exporta com.foo.bar.beta;}
Los miembros públicos de los paquetes com.foo.bar.alpha y com.foo.bar.beta serán accesibles por módulos dependientes. Los miembros privados son inaccesibles incluso a través de un medio como la reflexión , aunque si el 'acceso ilegal' está permitido de facto depende de la configuración de la línea de comandos. [13]
A diferencia del formato de archivo Jar, el módulo describirá estas dependencias en una declaración de módulo que se colocará en un archivo llamado module-info.java en la raíz de la jerarquía del archivo fuente del módulo. El JDK podrá verificar las dependencias e interacciones entre los módulos tanto en tiempo de compilación como en tiempo de ejecución. El propio JDK se ha modularizado en Java 9 . [14]
Vínculos con OSGi
El Java Module System no tiene la intención de admitir todas las funcionalidades que la plataforma OSGi admite actualmente (por ejemplo, el modelo de ciclo de vida y el registro de servicios). Sin embargo, Java Module System admitirá funciones que no son compatibles con OSGi, como la modularidad en tiempo de compilación y el soporte integrado para bibliotecas nativas. [15] En 2016 se publicaron un par de artículos que exploran cómo Java Module System y OSGi podrían interoperar. Estos se pueden encontrar en InfoQ [16] y también en OSGi Alliance Blog. [17]
Ver también
Referencias
- ^ "Sistema de módulo de plataforma Java (JSR 376)" . Oracle Corporation . Consultado el 2 de julio de 2018 .
- ^ a b "Proyecto Jigsaw" . Oracle Corporation . Consultado el 29 de noviembre de 2015 .
- ^ Mark Reinhold (20 de septiembre de 2009). "Es hora de ... Plan B" . Oracle Corporation . Consultado el 21 de junio de 2017 .
- ^ "JDK 9" . Oracle Corporation . Consultado el 24 de febrero de 2016 .
- ^ "Java 9: fecha de lanzamiento y nuevas funciones" . techworld.com. 2017-07-21 . Consultado el 18 de noviembre de 2017 .
- ^ "jlink: Java Linker (JSR 282)" . Oracle Corporation . Consultado el 12 de marzo de 2016 .
- ^ "Sistema de módulo de plataforma Java (JSR 376)" . Oracle Corporation . Consultado el 29 de noviembre de 2015 .
- ^ "JEP 238: archivos JAR de varias versiones" . Oracle Corporation . Consultado el 31 de julio de 2017 .
- ^ "JEP 253: preparar controles de interfaz de usuario JavaFX y API de CSS para modularización" . Oracle Corporation . Consultado el 31 de julio de 2017 .
- ^ "JEP 260: encapsular la mayoría de las API internas" . Oracle Corporation . Consultado el 31 de julio de 2017 .
- ^ "JEP 275: Empaquetado de aplicaciones Java modular" . Oracle Corporation . Consultado el 31 de julio de 2017 .
- ^ Mark Reinhold (8 de marzo de 2016). "El estado del sistema modular" . Oracle Corporation . Consultado el 18 de febrero de 2017 .
- ^ "JEP 396: encapsular fuertemente los componentes internos de JDK de forma predeterminada" . Consultado el 6 de febrero de 2021 .
- ^ "Resumen del módulo JDK" . Oracle Corporation . 2016-06-24 . Consultado el 18 de febrero de 2017 .
- ^ Mark Reinhold (24 de agosto de 2012). "Proyecto Jigsaw: tarde para el tren: el Q&A" . Oracle Corporation . Consultado el 29 de noviembre de 2015 .
- ^ "Java 9, OSGi y el futuro de la modularidad" . InfoQ . Consultado el 26 de septiembre de 2016 .
- ^ "Capas de módulo Java y paquetes OSGi" . Alianza OSGi . Consultado el 1 de agosto de 2016 .
enlaces externos
- JSR 277
- JSR 294
- JSR 376
- Proyecto Jigsaw
- El estado del sistema de módulos
- Sistema de módulo de plataforma Java: resumen de problemas