jre - java 9 jigsaw example

OSGi, Java Modularity y Jigsaw

Question

Entonces, a partir de ayer por la mañana, no tenía ni idea de qué era OSGi. OSGi era solo una palabra de moda que seguí viendo surgir una y otra vez, así que finalmente reservé un tiempo para repasarlo.

En realidad, parece algo muy bueno, así que me gustaría comenzar afirmando (para que conste) que no soy anti OSGi en ningún aspecto, ni tampoco es una pregunta "OSGi-bashing".

Al final del día, parece que OSGi ha abordado, en esencia, el JSR 277 sobre Modularidad Java, que reconoció que hay deficiencias con la especificación del archivo JAR que puede conducir a la resolución del espacio de nombres y problemas de carga de clases en ciertos casos de esquina. OSGi también hace muchas otras cosas geniales, pero por lo que puedo asegurar, ese es su mayor atractivo (o uno de ellos).

Para mí, como desarrollador de Java EE bastante nuevo (hace algunos años), es absolutamente alucinante que estemos en el año 2011 y que actualmente vivamos en la era de Java 7, y que estos problemas de carga de clases sigan presentes; particularmente en entornos empresariales donde un servidor de aplicaciones podría tener cientos de JARs, muchos de los cuales dependen de diferentes versiones entre sí y todos se ejecutan (más o menos) al mismo tiempo.

Mi pregunta:

Tan interesado como estoy en OSGi, y por mucho que quiera comenzar a aprender sobre él para ver dónde y si podría ser útil para mis proyectos, simplemente no tengo tiempo para sentarme y aprender algo tan grande, al menos ahora.

Entonces, ¿qué deben hacer los desarrolladores no OSGi cuando surgen estos problemas? ¿Qué soluciones Java (Oracle / Sun / JCP) existen actualmente, si las hay? ¿Por qué se cortó Jigsaw de J7? ¿Qué tan segura es la comunidad que Jigsaw implementará el próximo año en J8? ¿Es posible obtener Jigsaw para su proyecto a pesar de que todavía no forma parte de la plataforma Java?

Supongo que lo que estoy preguntando aquí es una combinación de pánico, intriga y cara. Ahora que finalmente entiendo qué es OSGi, simplemente no "entiendo" cómo algo como Jigsaw ha tardado más de 20 años en materializarse, y cómo podría haber sido conservado a partir de un lanzamiento. Simplemente parece fundamental.

Y, como desarrollador, también tengo curiosidad sobre cuáles son mis soluciones, sin OSGi.

Además, Nota : Sé que esta no es una pregunta tipo " programación pura ", pero antes de que algunos de ustedes se salgan de su forma, quise decir (nuevamente, para que conste en acta) que hice esta pregunta deliberadamente. ASI QUE. Eso es porque no tengo más que el máximo respeto por mis compañeros SOers y estoy buscando una respuesta a nivel arquitectónico de algunos de los "Dioses de TI" que veo al acecho aquí todos los días.

Pero, para aquellos de ustedes que insisten absolutamente en que una pregunta SO sea respaldada con algún segmento de código:

int x = 9;

(¡Gracias a cualquiera que pueda opinar sobre este tema OSGi / Jigsaw / classloader / namespace / JAR!)

Answer 1

Es simple, si quieres hacer un desarrollo real basado en componentes en Java hoy, entonces OSGi es el único juego de la ciudad.

En mi opinión, Jigsaw es una combinación de un compromiso de lo que es factible en el JDK y una mala relación previa entre SUN y los chicos de OSGi. Tal vez se envíe con Java 8, pero tenemos que esperar y ver.

OSGi no es una panacea si está trabajando en una configuración empresarial típica y tendrá que familiarizarse con cómo funciona la carga de clases, ya que varias bibliotecas conocidas (mirándolo, Hibernate) hicieron suposiciones sobre la visibilidad de clase que ya no son válidas dentro de OSGi.

Me gusta OSGi, pero no probaría y adaptarlo a un sistema existente. También sopesaría los pros y los contras en términos de desarrollo nuevo. Recomiendo mirar los productos Apache o Eclipse que simplifican la vida de OSGi y no hacerlo todo usted mismo.

Si no está haciendo OSGi, entonces no tiene suerte si ha creado un sistema que tiene dependencias en diferentes versiones de la misma biblioteca; todo lo que puede hacer es intentar evitar el problema, aunque necesita múltiples versiones de un la biblioteca me parece un "olor" arquitectónico.

Answer 2

Me encanta su uso de la frase "casos de esquina" para describir la situación actual.

hay deficiencias con la especificación del archivo JAR que puede conducir a la resolución del espacio de nombres y problemas de carga de clases en ciertos casos de esquina

De todos modos, desde hace muchos años me interesan las herramientas y técnicas que apoyan la creación y, aún mejor, la aplicación de un código más limpio, más desacoplado, más coherente y más fácil de mantener de lo que probablemente hubiera sido el resultado sin ellos. Test Driven Design y Junit fue una combinación.

Después de haber pasado un par de meses moviendo una parte sustancial de nuestro código base a OSGi, diría que OSGi es una herramienta aún mejor en este sentido. Y esa es realmente una razón suficiente para pasar a OSGi. A la larga, te ahorrará mucho dinero.

Y, como beneficio adicional, te dará la oportunidad de hacer muchas cosas interesantes. Imagínese, durante una demostración, actualizar sin problemas el módulo de autenticación, sin pérdida de tráfico, para admitir a OAuth ... ¡de pronto es una alegría volver a crear cosas!

Answer 3

Primero entiendo que el caso de uso primario de Jigsaw es modularizar el JRE. Como objetivo secundario, ofrecerá un sistema de módulos que pueden ser utilizados por otras bibliotecas y aplicaciones de Java.

Mi posición es que algo como Jigsaw probablemente sea necesario solo para el JRE, pero creará muchos más problemas de los que pretende resolver si se usan en otras bibliotecas o aplicaciones de Java.

El JRE es un caso muy difícil y especial. Tiene más de 12 años y es un desastre espantoso, plagado de ciclos de dependencia y dependencias sin sentido. Al mismo tiempo, es utilizado por aproximadamente 9 millones de desarrolladores y probablemente miles de millones de sistemas en ejecución. Por lo tanto, definitivamente no puede refactorizar el JRE si esa refactorización crea cambios de ruptura.

OSGi es un sistema de módulos que lo ayuda (o incluso lo obliga ) a crear software que es modular. No se puede simplemente rociar la modularidad sobre una base de código no modular existente. Para hacer una base de código no modular en una modular, inevitablemente se requiere una refactorización: mover las clases al paquete correcto, reemplazar la instanciación directa con el uso de servicios desacoplados, y así sucesivamente.

Esto hace que sea difícil aplicar OSGi directamente a la base de código de JRE, sin embargo, todavía tenemos el requisito de dividir el JRE en piezas separadas o "módulos" para que se puedan entregar versiones reducidas del JRE.

Por lo tanto, considero a Jigsaw como una especie de " medida extrema " para mantener vivo el código JRE mientras lo divido. No ayuda a que el código sea más modular, y estoy convencido de que realmente aumentará el mantenimiento requerido para desarrollar cualquier biblioteca o aplicación que lo use.

Finalmente: OSGi existe mientras que Jigsaw aún no existe y puede que nunca exista. La comunidad OSGi tiene 12 años de experiencia en el desarrollo de aplicaciones modulares. Si está realmente interesado en desarrollar aplicaciones modulares, OSGi es el único juego de la ciudad.