El sistema de administración de paquetes de Java siempre me pareció simple y efectivo. Es muy utilizado por el propio JDK. Lo hemos estado usando para imitar el concepto de espacios de nombres y módulos.
¿Qué intenta completar Project Jigsaw (también conocido como Java Platform Module System )?
Desde el sitio oficial:
El objetivo de este proyecto es diseñar e implementar un sistema de módulos estándar para la plataforma Java SE, y aplicar ese sistema a la propia plataforma y al JDK.
Respuestas:
Jigsaw y OSGi están tratando de resolver el mismo problema: cómo permitir que los módulos de grano más grueso interactúen mientras protegen sus partes internas.
En el caso de Jigsaw, los módulos de grano más grueso incluyen clases de Java, paquetes y sus dependencias.
Aquí hay un ejemplo: Spring e Hibernate. Ambos dependen de un JAR CGLIB de terceros, pero utilizan versiones diferentes e incompatibles de ese JAR. ¿Qué puede hacer si confía en el JDK estándar? Incluir la versión que Spring quiere rompe Hibernate y viceversa.
Pero, si tiene un modelo de nivel superior como Jigsaw, puede administrar fácilmente diferentes versiones de un JAR en diferentes módulos. Piense en ellos como paquetes de nivel superior.
Si construye Spring desde la fuente de GitHub , también lo verá. Han rehecho el marco, por lo que consta de varios módulos: núcleo, persistencia, etc. Puede elegir el conjunto mínimo de dependencias de módulos que necesita su aplicación e ignorar el resto. Solía ser un solo Spring JAR, con todos los archivos .class en él.
Actualización: Cinco años después, es posible que Jigsaw aún tenga algunos problemas que resolver.
NoSuchMethodErrory NoClassDefFoundError.
AFAIK El plan es hacer que el JRE sea más modular. Es decir, tiene frascos más pequeños que son opcionales y / o puede descargar / actualizar solo la funcionalidad que necesita.
Es para hacerlo menos hinchado y darle la opción de eliminar módulos heredados que quizás la mayoría de la gente no usa.
importtodo lo que hace es introducir esta clase en el espacio de nombres de la clase para el compilador. Si no lo usa, no aparecerá en el código de bytes creado. Si realmente usa la clase, necesita tener esa clase y todas las clases que usa en tiempo de ejecución. En teoría, podría crear una versión reducida de la API de guayaba que solo tuviera lo que necesita y usar ese JAR en su lugar. En realidad, esto es propenso a errores y no es muy útil en la mayoría de los casos, y termina agregando todo el JAR como se publicó.
Sobre la base de la marca Reinhold 's discurso en Devoxx Bélgica , Proyecto de Jigsaw se va a abordar dos puntos débiles principales:
Todos sabemos sobre el JAR Hell . Este término describe todas las diversas formas en que el proceso de carga de clases puede terminar sin funcionar. Las limitaciones más conocidas de classpath son:
La gran naturaleza monolítica de JDK causa varios problemas:
Para abordar los problemas anteriores, tratamos los módulos como un nuevo tipo fundamental de componente de programa Java. Un módulo es una colección de código y datos autodescriptivos con nombre. Su código está organizado como un conjunto de paquetes que contienen tipos, es decir, clases e interfaces Java; sus datos incluyen recursos y otros tipos de información estática.
Para controlar cómo su código se refiere a tipos en otros módulos, un módulo declara qué otros módulos necesita para ser compilado y ejecutado. Para controlar cómo el código de otros módulos se refiere a los tipos de sus paquetes, un módulo declara cuál de esos paquetes exporta.
El sistema de módulos ubica los módulos requeridos y, a diferencia del mecanismo de ruta de clases, asegura que el código en un módulo solo puede hacer referencia a tipos en los módulos de los que depende. Los mecanismos de control de acceso del lenguaje Java y la máquina virtual Java evitan que el código acceda a tipos en paquetes que no son exportados por sus módulos de definición.
Además de ser más confiable, la modularidad podría mejorar el rendimiento. Cuando el código en un módulo se refiere a un tipo en un paquete, se garantiza que ese paquete se definirá en ese módulo o precisamente en uno de los módulos leídos por ese módulo. Cuando se busca la definición de un tipo específico, por lo tanto, no es necesario buscarlo en múltiples módulos o, peor aún, a lo largo de toda la ruta de clases.
Jigsaw es un proyecto enorme que se lleva a cabo durante varios años. Tiene una cantidad impresionante de JEP que son excelentes lugares para obtener más información sobre el proyecto. Algunos de estos PEC son los siguientes:
En la edición inicial del informe El estado del sistema de módulos , Mark Reinhold describe los objetivos específicos del sistema de módulos de la siguiente manera:
Estas características beneficiarán a los desarrolladores de aplicaciones, desarrolladores de bibliotecas e implementadores de la propia plataforma Java SE de forma directa y, también, indirectamente, ya que permitirán una plataforma escalable, una mayor integridad de la plataforma y un rendimiento mejorado.
En aras del argumento, afirmemos que Java 8 (y versiones anteriores) ya tiene una "forma" de módulos (jar) y un sistema de módulos (la ruta de clases). Pero existen problemas bien conocidos con estos.
Al examinar los problemas, podemos ilustrar la motivación de Jigsaw. (Lo siguiente supone que no estamos utilizando OSGi, módulos JBoss, etc., que ciertamente ofrecen soluciones).
Problema 1: el público también público
Considere las siguientes clases (suponga que ambas son públicas):
com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl
En Foo.com, podríamos decidir que nuestro equipo debería usar UserDaoy no usarUserDaoImpl directamente. Sin embargo, no hay forma de hacer cumplir eso en la ruta de clases.
En Jigsaw, un módulo contiene un module-info.javaarchivo que nos permite indicar explícitamente qué es público para otros módulos. Es decir, el público tiene matices. Por ejemplo:
// com.acme.foo.db.api.UserDao is accessible, but
// com.acme.foo.db.impl.UserDaoImpl is not
module com.acme.foo.db {
exports com.acme.foo.db.api;
}
Problema 2: la reflexión es desenfrenada
Dadas las clases en el n. ° 1, alguien aún podría hacer esto en Java 8:
Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();
Es decir: la reflexión es poderosa y esencial, pero si no se controla, puede usarse para llegar a lo interno de un módulo de formas indeseables. Mark Reinhold tiene un ejemplo bastante alarmante . (La publicación SO está aquí ).
En Jigsaw, encapsulado fuerte ofrece la capacidad de denegar el acceso a una clase, incluida la reflexión. (Esto puede depender de la configuración de la línea de comandos, pendiente de la especificación técnica revisada para JDK 9.) Tenga en cuenta que debido a que Jigsaw se usa para el propio JDK, Oracle afirma que esto permitirá al equipo de Java innovar las partes internas de la plataforma más rápidamente.
Problema 3: la ruta de clases borra las relaciones arquitectónicas
Un equipo suele tener un modelo mental sobre las relaciones entre los frascos. Por ejemplo, foo-app.jarpuede usar foo-services.jarwhich uses foo-db.jar. Podríamos afirmar que las clases en foo-app.jarno deben pasar por alto "la capa de servicio" y utilizarlas foo-db.jardirectamente. Sin embargo, no hay forma de hacer cumplir eso a través del classpath. Mark Reinhold menciona esto aquí .
En comparación, Jigsaw ofrece un modelo de accesibilidad explícito y confiable para módulos.
Problema 4: tiempo de ejecución monolítico
El tiempo de ejecución de Java es monolítico rt.jar. En mi máquina, son más de 60 MB con 20k clases. En una era de microservicios, dispositivos IoT, etc., no es deseable tener Corba, Swing, XML y otras bibliotecas en el disco si no se están utilizando.
Jigsaw divide el propio JDK en muchos módulos; por ejemplo, java.sql contiene las conocidas clases SQL. Esto tiene varios beneficios, pero uno nuevo es la jlinkherramienta. Suponiendo que una aplicación está completamente modularizada, jlinkgenera una imagen en tiempo de ejecución distribuible que se recorta para contener solo los módulos especificados (y sus dependencias). De cara al futuro, Oracle prevé un futuro en el que los módulos JDK se compilan con anticipación en código nativo. Aunque jlinkes opcional y la compilación de AOT es experimental, son indicaciones importantes de hacia dónde se dirige Oracle.
Problema 5: control de versiones
Es bien sabido que el classpath no nos permite usar múltiples versiones del mismo jar: por ejemplo bar-lib-1.1.jary bar-lib-2.2.jar.
Jigsaw no aborda este problema; Mark Reinhold expone la razón fundamental aquí . La esencia es que Maven, Gradle y otras herramientas representan un gran ecosistema para la gestión de la dependencia, y otra solución será más dañina que beneficiosa.
Cabe señalar que otras soluciones (por ejemplo, OSGi) sí abordan este problema (y otros, además de la # 4).
Línea de fondo
Éstos son algunos de los puntos clave para Jigsaw, motivados por problemas específicos.
Tenga en cuenta que explicar la controversia entre Jigsaw, OSGi, JBoss Modules, etc. es una discusión separada que pertenece a otro sitio de Stack Exchange. Hay muchas más diferencias entre las soluciones que las que se describen aquí. Además, hubo suficiente consenso para aprobar la Boleta de reconsideración de revisión pública para JSR 376.
Este artículo explica en detalle los problemas que tanto OSGi como JPMS / Jigsaw intentan resolver:
"Java 9, OSGi y el futuro de la modularidad" [22 de septiembre de 2016]
También profundiza en los enfoques de OSGi y JPMS / Jigsaw. A partir de ahora, parece que los autores no enumeraron casi ningún pros práctico para JPMS / Jigsaw en comparación con OSGi maduro (16 años).