[vc_row][vc_column][vc_column_text]Java es utilizado para desarrollos de toda clase y tamaño, incluso para aplicaciones con millones de líneas de código. Evidentemente, Java ha realizado algo en forma correta para construir grandes sistemas, incluso antes de la llegada de Java 9. Examinemos los tres principios centrales de la modularidad de Java antes de la llegada de Java 9 y su sistema de módulos.

  • Encapsulación de tipos se puede lograr utilizando combinación de paquetes y modificadores de acceso (como private, protected o public). Haciendo una clase protected, por ejemplo, se puede prevenir que otras clases que no están en el paquete accedan a dicha clase. Esto lleva a una pregunta interesante: ¿Qué pasa si quieres que la clase se accesible por una clase de otro paquete, pero que aún no se pueda utilizar por otras clases?, no hay una manera adecuada de realizar esto. En este caso se puede hacer que la clase sea public. Pero public, significa publica para cualquiera en el sistema, significa no encapsulación.
  • En la sección de interfaces, Java lo ha estado haciendo bien desde su creación. Lo adivino, estamos hablando de las propias interfaces de Java. Exposición de una interface pública, mientras se oculta la clase de implementación detrás de un Factory o mediante una inyección de dependencias, esto es un método probado y que funciona. Se debe considerar que las interfaces juegan un papel fundamental en el Sistema Modular de Java 9.
  • En las dependencias explícitas es donde las cosas se vienen desmoronando. Si Java tiene declaración de importaciones explícitas. Desafortunadamente, esas importaciones son estrictamente una construcción en tiempo de compilación. Una vez que se empaqueta el código en un JAR, no se sabe que otros JAR’s contienen los tipos que su JAR necesita para ejecutar realmente. De hecho, este problema es tan malo que muchas herramientas externas evolucionaron junto con el lenguaje Java para resolver este problema, tales como Maven y OSGi.

Tal como se encuentra Java, ofrece una solución sólida para construir aplicaciones de gran tamaño, mas también es claro que la modularidad es un aspecto a mejorar.

¿JARs como módulos?

Los JARs o librerías de Java se observa como algo muy parecido a los módulos previos a Java 9. Ellos tienen un nombre, agrupados por código relacionado y pueden definir interfaces públicas muy bien definidas. Observemos un ejemplo de una aplicación típica de Java.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column css=».vc_custom_1502316124307{margin-top: 0px !important;margin-bottom: 0px !important;padding-top: 0px !important;padding-bottom: 0px !important;}»][vc_single_image image=»1076″ img_size=»full»][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

Es una aplicación llamada MyApplication.jar con código estándar. Esta aplicación utiliza dos librerías: Google Guava y Hibernate Validator. Además se tienen tres librerías adicionales. Estas librerías adicionales son dependencias de Hibernate Validator, dependencias que se pueden resolver utilizando Maven. MyApplication se ejecuta con una versión de JDK previa a la versión 9, la cual en sí misma expone varias librerías de la plataforma.

Si observamos los paquetes de cerca, se puede observar que hay clases como com.google.common.base.internal.Finalizer que es utilizada por Guava, pero que no es parte del API oficial. Es una clase pública desde que otros paquetes de Guava hacen uso de Finalizer. Desafortunadamente esto también significa que no hay impedimento para que com.myapp.Main pueda utilizar esta clase. En otras palabras el encapsulamiento es débil.

Como se observa, esto puede ocurrir con muchas clases, haciendo que el encapsulamiento en los proyectos sea débil.

¿Qué pasa con las dependencias? Como hemos aprendido, no hay información de dependencias cuando se observa estrictamente a los JARs. Para ejecutar MyApplication, se tiene:

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column css=».vc_custom_1502316133770{margin-top: 0px !important;margin-bottom: 0px !important;padding-top: 0px !important;padding-bottom: 0px !important;}»][vc_single_image image=»1074″ img_size=»full»][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]El indicar la ruta de las librerías depende del usuario. Y, sin información explicita de las dependencias es para tener mucho cuidado.

Módulos en Java 9

De lo revisado, se puede tener una comprensión de las fortalezas y limitaciones actuales de Java al hablar de modularidad. Con Java 9 tenemos un nuevo aliado en el camino de estructurar adecuadamente una aplicación: el sistema de módulos de Java. Al diseñar la Java Platform Module System para superar las limitaciones actuales, se definieron dos objetivos principales:

  • Modularizar el JDK en sí mismo
  • Ofrecer un sistema de módulos para que las aplicaciones lo utilicen

Estos objetivos se encuentran muy relacionados. La modularización del JDK se ha realizado utilizando los mismos principios del sistema de módulos que nosotros como desarrolladores realizaremos en Java 9.

Revisemos el ejemplo de MyApplication utilizando el sistema de modulos de Java 9:[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column css=».vc_custom_1502316144939{margin-top: 0px !important;margin-bottom: 0px !important;padding-top: 0px !important;padding-bottom: 0px !important;}»][vc_single_image image=»1075″ img_size=»full»][/vc_column][/vc_row][vc_row][vc_column][vc_column_text css=».vc_custom_1502316096070{margin-top: 0px !important;margin-bottom: 0px !important;padding-top: 0px !important;padding-bottom: 0px !important;}»]

Cada JAR se convierte en un módulo, con referencias explícitas para otro modulo. El hecho de que hibernate-validator utilice jboss-logging, classmate y validation-api es parte del descriptor de módulos. El modulo tiene una parte pública accesible y una parte encapsulada. De esta forma MyApplication no utiliza la clase Finalizer de la librería Guava. A través de este diagrama, se puede observar que MyApplication utiliza validation-api. Así mismo, MyApplication tiene una dependencia explícita a un módulo del JD denominado java.sql.

Con el nuevo sistema de módulos de Java 9 ahora se tiene una encapsulación fuerte, adecuada definición de interfaces y dependencias explicitas como parte de la plataforma de Java.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]


Artículo tomado del Capitulo 1 del libro Java 9 Modularity, escrito por Sander Mak; Paul Bakker.[/vc_column_text][/vc_column][/vc_row]

Java 9 y el Sistema de Modulos
Si te gusto, comparte ...Share on email
Email
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
Linkedin
Share on google
Google
Etiquetado en:            

2 pensamientos en “Java 9 y el Sistema de Modulos

  • Pingback: Java 9 ahora tiene soporte con Gradle

  • enero 9, 2018 a las 11:20 pm
    Enlace permanente

    Hola primero que nada agradezco la introducción que nos proporcionas para adentrarnos a java 9.

    Ojalá me pudieras ayudar, ya que ando un poco perdido, anteriormente con java 8 generabas un jar y lo podías ejecutar con doble clic y con solo tener la carpeta lib con tus dependencias automáticamente las tomaba, mi duda es, en java 9 como obtengo dicho jar y que automáticamente al ejecutar con doble clic dicho jar ya sepa que modulos se ejecutan o a caso solo puedo correrlo a través de la consola? me puedes orientar un poco si es posible.

    Gracias

    Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Facebook