Descripción de Java 9 Modules

Qué son y cómo utilizarlos

Por Paul Deitel

Paul Deitel

En este artículo, presento el sistema de módulos de plataforma (JPMS) Java 9, la nueva tecnología de ingeniería de software más importante de Java desde su creación. La modularidad, resultado de Project Jigsaw, ayuda a los desarrolladores de todos los niveles a ser más productivos a medida que crean, mantienen y desarrollan sistemas de software, especialmente sistemas grandes.

¿Qué es un módulo?

Modularity agrega un mayor nivel de agregación por encima de los paquetes. El nuevo elemento clave es el módulo, un grupo de paquetes reutilizable con nombre único, y recursos (como imágenes y archivos XML) y un descriptor de módulo que especifica

• el nombre del módulo
• las dependencias del módulo (es decir, otros módulos de los que depende este módulo)
• los paquetes que pone a disposición de otros módulos de forma explícita (todos los demás paquetes del módulo están implícitamente no disponibles para otros módulos)
• los servicios que ofrece
• los servicios que consume
• a qué otros módulos permite reflexión

Historial

La plataforma Java SE ha existido desde 1995. Ahora hay aproximadamente 10 millones de desarrolladores que lo utilizan para crear todo, desde pequeñas aplicaciones para dispositivos con recursos limitados, como los del Internet de las cosas (IoT) y otros dispositivos integrados, hasta sistemas esenciales para el negocio a gran escala. Ahí hay una gran cantidad de código heredado, pero hasta ahora la plataforma Java ha sido principalmente una solución monolítica única para todos. A lo largo de los años, se han realizado varios esfuerzos orientados a modularizar Java, pero ninguno se utiliza ampliamente, y ninguno se puede utilizar para modularizar la plataforma Java.

La modularización de la plataforma Java SE ha sido difícil de implementar y el esfuerzo ha llevado muchos años. JSR 277: Java Module System se propuso originalmente en 2005 para Java 7. Posteriormente, este JSR fue sustituido por JSR 376: sistema de módulo de plataforma Java y dirigido a Java 8. La plataforma Java SE ahora está modularizada en Java 9, pero solo después de que Java 9 se retrasara hasta septiembre de 2017.

Objetivos

Según JSR 376, los objetivos clave de la modularización de la plataforma Java SE son:

• COnfiguración confiable: Modularity proporciona mecanismos para declarar explícitamente dependencias entre módulos de una manera que se reconoce tanto en tiempo de compilación como en tiempo de ejecución. El sistema puede recorrer estas dependencias para determinar el subconjunto de todos los módulos necesarios para soportar su aplicación.
• Encapsulación compleja: los paquetes de un módulo son accesibles para otros módulos sólo si el módulo los exporta explícitamente. Incluso entonces, otro módulo no puede utilizar esos paquetes a menos que indique explícitamente que requiere las capacidades del otro módulo. Esto mejora la seguridad de la plataforma porque hay menos clases accesibles para posibles atacantes. Puedes darte cuenta de que la modularidad te ayuda a dar con diseños más limpios y más lógicos.
• Plataforma Java escalable: anteriormente, la plataforma Java era un monolito compuesto por un gran número de paquetes, lo que hacía difícil desarrollar, mantener y evolucionar. No era fácil crear subjuegos. La plataforma ahora está dividida en 95 módulos (este número puede cambiar a medida que evoluciona Java). Puedes crear tiempos de ejecución personalizados que consten solo de los módulos que necesites para las aplicaciones o los dispositivos a los que se dirige. Por ejemplo, si un dispositivo no admite GUI, puedes crear un tiempo de ejecución que no incluya los módulos de GUI, lo que reduce significativamente el tamaño del tiempo de ejecución.
• Mayor integridad de la plataforma: antes de Java 9, era posible utilizar muchas clases de la plataforma que no estaban destinadas a las clases de una aplicación. Con una encapsulación sólida, estas API internas están realmente encapsuladas y ocultas a las aplicaciones que utilizan la plataforma. Esto puede hacer que la migración de código heredado a Java 9 modularizado sea problemática si el código depende de las API internas.
• Rendimiento mejorado: JVM utiliza varias técnicas de optimización para mejorar el rendimiento de la aplicación. JSR 376 indica que estas técnicas son más eficaces cuando se sabe de antemano que los tipos requeridos están ubicados solo en módulos específicos.

Enumeración de los módulos de JDK

Un aspecto crucial de Java 9 es dividir el JDK en módulos para soportar diversas configuraciones. Consulta "JEP 200: The Modular JDK". Todos los JEP y JSR de modularidad de Java se muestran en la tabla 1). Mediante el comando java de la carpeta bin de JDK con la opción --list-modules, como en: 

muestra el juego de módulos de JDK, que incluye los módulos estándar que implantan la especificación SE de lenguaje Java (nombres que empiezan por java), módulos JavaFX (nombres que empiezan por javafx), módulos específicos de JDK (nombres que empiezan por jdk) y módulos específicos de Oracle (nombres que empiezan por oracle). Cada nombre de módulo va seguido de una cadena de versión: @9 indica que el módulo pertenece a Java 9.

Declaraciones de módulo

Como hemos mencionado, un módulo debe proporcionar su descriptor: metadatos que especifiquen las dependencias del módulo, los paquetes que el módulo pone a disposición de otros módulos, y mucho más. Un descriptor de módulo es la versión compilada de una declaración de módulo que está definida en un archivo denominado module-info.java. Cada declaración de módulo comienza con la palabra clave module, seguida de un nombre de módulo único y un cuerpo de módulo entre corchetes, como en:

El cuerpo de la declaración del módulo puede estar vacío o puede contener varias directivas de módulo, comorequires, exports, provides…with, uses y opens (nos detendremos en cada una de ellas). Como verás más adelante, la compilación de la declaración del módulo crea el descriptor del módulo, que se almacena en un archivo denominado module-info.class en la carpeta raíz del módulo. Aquí presentamos brevemente cada directiva sobre módulos. Después de eso, presentaremos las declaraciones reales del módulo.

Las palabras clave exports, module, open, opens, provides, requires, uses, with, así como to y transitive, que presentamos más adelante, son palabras clave restringidas. Son palabras clave solo en declaraciones de módulo y se pueden utilizar como identificadores en cualquier otro lugar del código.

requieres. Una directiva de módulo requires especifica que este módulo depende de otro módulo; esta relación se denomina dependencia de módulo. Cada módulo debe establecer explícitamente sus dependencias. Cuando el módulo A requires módulo B, el módulo A se dice para read módulo B y el módulo B se read by módulo A. Para especificar una dependencia en otro módulo, utiliza requires, como en:

También hay una directiva requires static para indicar que un módulo es necesario en tiempo de compilación, pero es opcional en tiempo de ejecución. Esto se conoce como dependencia opcional y no se tratará en esta introducción.

requiere legibilidad implícita transitiva. Para especificar una dependencia en otro módulo y asegurarte de que otros módulos que leen el módulo también lean esa dependencia, conocida como implied readability, utiliza requires transitive, como en el siguiente ejemplo:

Ten en cuenta la siguiente directiva de la declaración del módulo java.desktop:

En este caso, cualquier módulo que lea java.desktop también lee implícitamente java.xml. Por ejemplo, si un método del módulo java.desktop devuelve un tipo del módulo java.xml, el código de los módulos que leen java.desktop depende de java.xml. Sin la directiva requires transitive en la declaración de módulo de java.desktop, dichos módulos dependientes no se compilarán a menos que explícitamente lean java.xml.

Según JSR 379, los módulos estándar de Java SE deben otorgar legibilidad implícita en todos los casos como el que se describe aquí. Además, aunque un módulo estándar Java SE puede depender de módulos no estándar, must not otorgarles legibilidad implícita. Esto garantiza que el código que depende únicamente de los módulos estándar de Java SE sea portátil en las implantaciones de Java SE.

exports and exports…to. Una directiva de módulo exports especifica uno de los paquetes del módulo cuyos tipos public (y sus tipos public y protected anidados) deben ser accesibles para el código en todos los demás módulos. Una directiva exports…to permite especificar en una lista separada por comas con precisión qué código de módulo o módulo puede acceder al paquete exportado, lo que se conoce como exportación qualified. 

uses. Una directiva de módulo uses especifica un servicio utilizado por este módulo, lo que convierte al módulo en un consumidor de servicios. Un service es un objeto de una clase que implementa la interfaz o amplía la clase abstract especificada en la directiva uses.

provides...with. Una directiva de módulo provides…with especifica que un módulo proporciona una implementación de servicio, lo que convierte al módulo en un service provider. La parte provides de la directiva especifica una interfaz o clase abstract que aparece en la directiva uses de un módulo y la parte with de la directiva especifica el nombre de la clase de proveedor de servicios que implements la interfaz o extends la clase abstract.

open, opens, and opens…to. Antes de Java 9, la reflexión se podría utilizar para conocer todos los tipos de un paquete y todos los miembros de un tipo, incluso sus miembros private, tanto si desea permitir esta capacidad como si no. Por lo tanto, nada estaba realmente encapsulado.

Una motivación clave del sistema del módulo es la encapsulación fuerte. De manera predeterminada, otros módulos no pueden acceder a un tipo de módulo, a menos que sea de tipo público y exporte su paquete. Puedes exponer solo los paquetes que deseas exponer. Con Java 9, esto también se aplica a la reflexión.

Permitir acceso solo en tiempo de ejecución a un paquete. Una directiva de módulo de aperturas del formulario

Indica que los tipos public de un paquete específico (y sus tipos public y protected anidados) son accesibles para el código en otros módulos solo en tiempo de ejecución. Además, se puede acceder a todos los tipos del paquete especificado (y a todos los miembros de los tipos) mediante reflexión.

Permitir el acceso solo de tiempo de ejecución a un paquete por módulos específicos. Una directiva de módulo opens…to con el formato

Indica que los tipos public de un package específico (y sus tipos public y protected anidados) son accesibles para el código en los módulos enumerados únicamente en tiempo de ejecución. Se puede acceder a todos los tipos del paquete especificado (y a todos los miembros de los tipos) mediante la reflexión del código en los módulos especificados.

Permitir acceso solo en tiempo de ejecución a todos los paquetes de un módulo. Si todos los paquetes de un módulo determinado deben ser accesibles en tiempo de ejecución y mediante la reflexión a todos los demás módulos, puedes open todo el módulo, como en:

Valores por defecto de reflejo

Por defecto, un módulo con acceso reflectante en tiempo de ejecución a un paquete puede ver los tipos public del paquete (y sus tipos public y protected anidados). Sin embargo, el código de otros módulos puede acceder a all los tipos del paquete expuesto y all los miembros de esos tipos, incluidos los miembros private a través de setAccessible, como en versiones anteriores de Java.

Para obtener más información sobre setAccessible y la reflexión, consulta la documentación de Oracle.

Paul Deitel, CEO y director técnico de Deitel & Associates, es graduado de MIT con 35 años de experiencia en computación. Es experto en Java y lleva más de 22 años programando en Java. Él y su coautor, el Dr. Harvey M. Deitel, son los autores de lenguajes de programación más vendidos del mundo. Paul ha impartido cursos de programación en Java, Android, iOS, C#, C++, C e Internet a clientes del sector, gubernamentales y académicos a nivel internacional.

NOTA: este artículo se tomó de Java Magazine septiembre/octubre de 2017.