Pregunta ¿Por qué proyecto Jigsaw / JPMS?


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.

Que es Proyecto Jigsaw (aka Sistema de módulo de plataforma Java) tratando de completar?

Desde el sitio oficial:

El objetivo de este proyecto es diseñar e implementar un módulo estándar   sistema para la plataforma Java SE, y aplicar ese sistema a la   Plataforma en sí y al JDK.


73
2017-08-07 11:20


origen


Respuestas:


Jigsaw y OSGi están tratando de resolver el mismo problema: cómo permitir que los módulos de grano grueso interactúen mientras protegen sus partes internas.

En el caso de Jigsaw, los módulos de grano más grueso incluyen clases Java, paquetes y sus dependencias.

Aquí hay un ejemplo: Spring e Hibernate. Ambos tienen una dependencia en un JAR CGLIB de terceros, pero usan versiones diferentes e incompatibles de ese JAR. ¿Qué puede hacer si confía en el estándar JDK? Incluyendo 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 mayor nivel.

Si construyes Primavera de la fuente GitHub lo verás también. Han rediseñado el marco, por lo que consta de varios módulos: núcleo, persistencia, etc. Puede seleccionar y elegir el conjunto mínimo de dependencias de módulo que su aplicación necesita e ignorar el resto. Solía ​​ser un Spring JAR único, con todos los archivos .class en él.

Actualización: cinco años después - Jigsaw aún podría tener algunos cuestiones resolver.


97
2017-08-07 11:27



AFAIK El plan es hacer que el JRE sea más modular. Es decir. Tenga frascos más pequeños que son opcionales y / o puede descargar / actualizar solo la funcionalidad que necesita.

Es para hacerlo menos hinchado y le da la opción de descartar módulos heredados que quizás la mayoría de la gente no usa.


41
2017-08-07 11:27



Residencia en Mark Reinholdes discurso de apertura en Devoxx Bélgica, Proyecto Jigsaw va a abordar dos puntos principales de dolor:

  1. Classpath
  2. Massive Monolithic JDK

¿Qué pasa con Classpath?

Todos sabemos sobre el JAR Hell. Este término describe todas las diversas formas en que carga de clases proceso puede terminar no funcionando. Las limitaciones más conocidas de classpath son:

  • Es difícil saber si hay conflictos. Las herramientas de compilación como maven pueden hacer un buen trabajo basado en nombres de artefactos, pero si los artefactos tienen los mismos nombres pero los mismos contenidos, podría haber un conflicto.
  • El problema fundamental con los archivos jar es que no son componentes. Son solo un montón de contenedores de archivos que se buscarán linealmente. Classpath es una forma de buscar clases sin importar en qué componentes están, en qué paquetes están o en qué uso están destinados.

Massive Monolithic JDK

La gran naturaleza monolítica de JDK causa varios problemas:

  • No cabe en dispositivos pequeños. Aunque los dispositivos pequeños de tipo IoT tienen procesadores capaces de ejecutar una VM de clase SE, pero no necesariamente tienen la memoria para contener todo el JDK, especialmente cuando la aplicación solo usa una pequeña parte de ella.
  • Incluso es un problema en la nube. Cloud se trata de optimizar el uso del hardware, si tienes miles de imágenes que contienen todo el JDK pero las aplicaciones solo usan una pequeña parte, sería un desperdicio.

Módulos: la solución común

Para abordar los problemas anteriores, tratamos los módulos como un nuevo tipo fundamental de componente de programa Java. Un módulo es una recopilación de códigos y datos con nombre y autodescripción. Su código está organizado como un conjunto de paquetes que contienen tipos, es decir, clases e interfaces de Java; sus datos incluyen recursos y otros tipos de información estática.

Para controlar cómo su código se refiere a los tipos en otros módulos, un módulo declara qué otros módulos requiere para compilarse y ejecutarse. Para controlar cómo el código en otros módulos se refiere a los tipos en sus paquetes, un módulo declara cuál de esos paquetes exporta.

El sistema de módulos localiza los módulos requeridos y, a diferencia del mecanismo de ruta de clases, asegura que el código en un módulo solo puede referirse a los tipos en los módulos de los que depende. Los mecanismos de control de acceso del lenguaje Java y la máquina virtual Java impiden que el código acceda a los tipos en paquetes que no son exportados por sus módulos definidores.

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 dicho paquete se definirá en ese módulo o en uno de los módulos leídos por ese módulo. Al buscar la definición de un tipo específico, por lo tanto, no hay necesidad de buscarlo en múltiples módulos o, lo que es peor, a lo largo de toda la ruta de clase.

PECs a seguir

Jigsaw es un proyecto enorme que está en marcha desde hace unos 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:

  • JEP 200: el JDK modular: Utilice el Sistema de Módulo de Plataforma Java (JPMS) para modularizar el JDK
  • JEP 201: código fuente modular: Reorganice el código fuente de JDK en módulos, mejore el sistema de compilación para compilar módulos y haga cumplir los límites del módulo en tiempo de compilación.
  • JEP 261: sistema de módulos: Implemente el Sistema de Módulo de Plataforma Java, según lo especificado por JSR 376, junto con los cambios y mejoras específicos relacionados con JDK.
  • JEP 220: imágenes modulares en tiempo de ejecución: Reestructurar las imágenes JDK y JRE en tiempo de ejecución para acomodar módulos y mejorar el rendimiento, la seguridad y la capacidad de mantenimiento
  • JEP 260: encapsula la mayoría de las API internas: Hacer que la mayoría de las API internas del JDK sean inaccesibles por defecto, pero deje acceso a algunas API internas ampliamente utilizadas y críticas, hasta que existan reemplazos admitidos para todas o la mayoría de sus funciones
  • JEP 282: jlink: el enlazador de Java: 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 como se define en JEP 220

Palabras de clausura

En la edición inicial de El estado del sistema de módulos informe, Mark Reinhold describe los objetivos específicos del sistema de módulos de la siguiente manera:

  • Configuración confiable, para reemplazar el mecanismo de ruta de clase frágil y propenso a errores con un medio para que los componentes de programa declaren dependencias explícitas entre sí, junto con
  • Encapsulación fuerte, para permitir que un componente declare cuáles de sus tipos públicos son accesibles para otros componentes, y cuáles no.

Estas características beneficiarán a los desarrolladores de aplicaciones, desarrolladores de bibliotecas e implementadores de la plataforma Java SE directamente y, también, indirectamente, ya que permitirán una plataforma escalable, una mayor integridad de la plataforma y un mejor rendimiento.


39
2018-01-15 14:47



Por el bien del argumento, afirmemos que Java 8 (y anteriores) ya tiene una "forma" de módulos (jarras) y sistema de módulos (el classpath). Pero hay problemas bien conocidos con estos.

Al examinar los problemas, podemos ilustrar la motivación para Jigsaw. (Lo siguiente asume que no estamos usando OSGi, JBoss Modules, etc., que ciertamente ofrecen soluciones).

Problema 1: público es 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, podemos decidir que nuestro equipo debería usar UserDao y no usar UserDaoImpl directamente. Sin embargo, no hay forma de aplicar eso en el classpath.

En Jigsaw, un módulo contiene una module-info.java archivo 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 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, se puede usar para alcanzar las partes internas de un módulo de formas no deseadas. Mark Reinhold tiene una ejemplo alarmante. (La publicación SO es aquí.)

En Jigsaw, fuerte encapsulación ofrece la posibilidad de denegar el acceso a una clase, incluida la reflexión. (Esto puede depender de la configuración de la línea de comandos, a la espera de la especificación técnica revisada para JDK 9.) Tenga en cuenta que debido a que Jigsaw se usa para el JDK, Oracle afirma que esto permitirá que el equipo de Java innove los componentes internos de la plataforma más rápidamente.

Problema 3: el classpath borra las relaciones arquitectónicas

Un equipo generalmente tiene un modelo mental sobre las relaciones entre jarras. Por ejemplo, foo-app.jar puede usar foo-services.jar que usa foo-db.jar. Podríamos afirmar que las clases en foo-app.jar no debe omitir "la capa de servicio" y usar foo-db.jar directamente. Sin embargo, no hay forma de aplicar eso a través del classpath. Marcos Reinhold menciona esto aqui.

En comparación, Jigsaw ofrece un modelo de accesibilidad explícito y confiable para los módulos.

Problema 4: tiempo de ejecución monolítico

El tiempo de ejecución de Java está en el monolítico rt.jar. ¡En mi máquina, es más de 60 MB con 20k clases! En una era de micro-servicios, dispositivos IoT, etc., no es deseable tener Corba, Swing, XML y otras bibliotecas en el disco si no se están utilizando.

Rompecabezas rompe el JDK en sí en muchos módulos; p.ej. java.sql contiene las clases de SQL familiares. Hay varios beneficios para esto, pero uno nuevo es el jlink herramienta. Asumiendo que una aplicación está completamente modularizada, jlink genera un imagen distribuible en tiempo de ejecución que está recortado para contener solo los módulos especificados (y sus dependencias). Mirando hacia adelante, Oracle visualiza un futuro donde los módulos JDK se compilan antes de tiempo en el código nativo. Aunque jlink es opcional, y la compilación AOT es experimental, son indicaciones importantes de hacia dónde se dirige Oracle.

Problema 5: control de versiones

Es bien sabido que classpath no nos permite usar varias versiones del mismo jar: p. bar-lib-1.1.jar y bar-lib-2.2.jar.

Jigsaw no aborda este problema; Mark Reinhold afirma que razonamiento 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) abordan este problema (y otras, aparte del n. ° 4).

Línea de fondo

Estos son algunos 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 por separado que pertenece a otro sitio de Stack Exchange. Hay muchas más diferencias entre las soluciones que las aquí descritas. Además, hubo suficiente consenso para aprobar el Boleta de reconsideración de revisión pública para JSR 376.


10
2018-06-15 18:03



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 SEP 2016]

También profundiza en los enfoques de OSGi y JPMS / Jigsaw. A partir de ahora, parece que los autores casi no enumeraron Pros prácticos para JPMS / Jigsaw en comparación con OSGi madurado (16 años).


2
2017-11-11 06:20