OSGi, Java Modularity y Jigsaw

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

En realidad, parece algo bastante interesante, así que me gustaría comenzar diciendo (para que conste) que no soy anti-OSGi en ningún aspecto, ni que esta es una pregunta de "ataque a OSGi".

Al final del día, parece que OSGi ha abordado, esencialmente, JSR 277 en Java Modularity, que reconoció que hay deficiencias con la JARespecificación del archivo que pueden conducir a la resolución del espacio de nombres y problemas de carga de clases en ciertos casos extremos. OSGi también hace muchas otras cosas realmente interesantes, pero por lo que puedo asegurar, ese es su mayor atractivo (o uno de ellos).

Para mí, como desarrollador Java EE relativamente nuevo (hace unos 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 JAR, muchos de ellos dependiendo de diferentes versiones entre sí y todos ejecutándose (más o menos) al mismo tiempo.

Mi pregunta:

Por más interesado que esté en OSGi, y por mucho que quiera comenzar a aprender sobre él para ver dónde / 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 que no son 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 está la comunidad de que Jigsaw se implementará el próximo año en J8? ¿Es posible obtener Jigsaw para su proyecto aunque aún no forme parte de la plataforma Java?

Supongo que lo que pregunto aquí es una combinación de pánico, intriga y palmas. 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 luego cómo podría haberse enlatado a partir de un lanzamiento. Simplemente parece fundamental.

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

Además, Nota : sé que esta no es una pregunta de tipo " programación pura ", pero antes de que algunos de ustedes pierdan la forma, quería decir (nuevamente, para que conste) que deliberadamente planteé esta pregunta ENTONCES. Eso es porque no tengo nada más que el mayor respeto por mis compañeros SOers y estoy buscando una respuesta a nivel arquitectónico de algunos de los "dioses de la TI" que veo acechando por aquí todos los días.

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

int x = 9;

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

Primero, comprenda que el caso de uso principal de Jigsaw es modularizar el propio JRE. Como objetivo secundario, ofrecerá un sistema de módulos que pueden utilizar otras bibliotecas y aplicaciones de Java.

Mi posición es que algo como Jigsaw probablemente sea necesario solo para JRE, pero creará muchos más problemas de los que pretende resolver si lo usan 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, lo utilizan aproximadamente 9 millones de desarrolladores y probablemente miles de millones de sistemas en ejecución. Por lo tanto, absolutamente no puede refactorizar el JRE si esa refactorización crea cambios importantes.

OSGi es un sistema de módulos que le ayuda (o incluso le obliga a) crear software modular. No puede simplemente esparcir modularidad sobre una base de código no modular existente. Convertir una base de código no modular en una modular inevitablemente requiere cierta refactorización: mover las clases al paquete correcto, reemplazar la instanciación directa con el uso de servicios desacoplados, etc.

Esto hace que sea difícil aplicar OSGi directamente al código base de JRE, sin embargo, todavía tenemos el requisito de dividir el JRE en partes 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 se divide. Lo hace sin código de ayuda para ser más modular, y estoy convencido de que va a aumentar el mantenimiento requerido para desarrollar cualquier biblioteca o aplicación que lo utiliza.

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 disponible.

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

En mi opinión, Jigsaw es una combinación de un compromiso de lo que es factible en el JDK y la mala relación anterior 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 un entorno empresarial típico y necesitará familiarizarse con el funcionamiento de la carga de clases, ya que varias bibliotecas conocidas (mirándolo a usted, Hibernate) hicieron suposiciones sobre la visibilidad de clases que ya no son válidas. dentro de OSGi.

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

Si no está utilizando OSGi, entonces no tendrá 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 varias versiones de un La biblioteca me parece un "olor" a arquitectura.

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 pueden conducir a problemas de resolución de espacio de nombres y carga de clases en ciertos casos extremos

De todos modos, desde hace muchos años me interesan las herramientas y técnicas que apoyan la creación y, mejor aún, el cumplimiento 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 ellas. Test Driven Design y Junit fue una combinación de este tipo.

Después de haber pasado un par de meses moviendo una parte sustancial de nuestra base de código 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, le ahorrará mucho dinero.

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