Su búsqueda no coincide con ningún resultado.
Le sugerimos que pruebe lo siguiente para poder encontrar lo que está buscando:
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.
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
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.
Cada módulo debe establecer explícitamente sus dependencias.
Según JSR 376, los objetivos clave de la modularización de la plataforma Java SE son:
JEP 200: EL JDK MODULAR
JEP 201: CÓDIGO FUENTE MODULAR
JEP 220: IMÁGENES DE TIEMPO DE EJECUCIÓN MODULARES
JEP 260: ENCAPSULADO DE MÁS APLICACIONES INTERNAS
JEP 261: SISTEMA DE MÓDULOS
JEP 275: EMPAQUETADO DE APLICACIONES JAVA MODULAR
JEP 282: JLINK: THE JAVA LINKER
JSR 376: JAVA PLATFORM MODULE SYSTEM
JSR 379: JAVA SE 9
Tabla 1. Java Modularity JEPs and JSRs
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:
java --list-modules
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.
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:
Una motivación clave del sistema del módulo es la encapsulación fuerte.
módulo modulename {
}
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:
requiere modulename;
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:
requiere modulename transitivo;
Ten en cuenta la siguiente directiva de la declaración del módulo java.desktop
:
requiere java.xml
transitivo;
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
opens package
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
opens package to comma-separated-list-of-modules
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:
open module modulename {
// module directives
}
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.