Porque OSGI no y Jigsaw si para modularización en java

Hace algún tiempo me tope con la necesidad de programar un componente de una aplicación de OAM (plugin) que se basaba en una implementación de OSGi, y bueno resulto ser un reto para mí ya que yo desconocía del todo el framework de la implementación (Apache Felix), sin dejar de lado que los manuales para desarrolladores de plugins de OAM traen ejemplos sencillos que no abarcan todas las variantes que puedes llegar a utilizar por ejemplo en mi caso tenía que consumir servicios web, y el manual solo tenía un ejemplo de como realizar una conexión a una base de datos. seguí los pasos que marcaba el manual y no funcionaba lo que había desarrollado porque el cargador de clases no llegaba a ver algunas clases necesarias para mi consumo de servicios (QName y algunas otras), fue así que decidimos leer acerca del framework en el que se basaba que era Apache Felix, el cual nos llevo a documentarnos y visitar de foro en foro hasta llegar a la página de OSGi Alliance.

Al igual que yo y la mayoría de la gente que lea esta entrada de blog y no conozca OSGi se preguntarán:

¿ Que fregados es OSGi ?

Retomado de este viejo post

El acrónimo ha pasado a ser el nombre oficial, nombre que en sus orígenes era Open Services Gateway initiative

OSGi tiene como objetivo la modularización de aplicaciones:

La especificación OSGi propone una arquitectura montada sobre una JVM que permita la instalación, actualización y eliminación de módulos. Cada módulo podrá publicar las clases que serán visibles por otros módulos de la máquina virtual y podrá consumir cualquier clase que haya sido publicada por otros módulos de la VM.

¿ Como logra la modularización OSGi ?

OSGi utiliza una especie de contenedores "especiales" llamados bundles (módulos), los cuales puedo definir terranalmente y ojo no es que mi definición sea la correcta o idónea como paquetes jar con ciertos metadatos contenidos en el archivo de manifiesto, en donde se puede definir si el bundle necesita algún otro bundle desplegado (para importar bibliotecas), si va exportar bibliotecas, definir la versión, autor, etc.

A continuación dejo un pequeño ejemplo de un archivo de manifiesto que use:

Modularización de Java

La comunidad de desarrollo Java inherentemente desde hace tiempo busca un mecanismo para llevar a cabo esta modularización dentro del propio JRE, algunas personas postulaban a OSGi hace algunos años como el candidato fuerte sin embargo se creo el proyecto Jigsaw que busca desacoplar el core de java en varios módulos, dicho proyecto estaba pactado como release para JDK 8 sin embargo se tuvo que postergar para JDK 9.

OSGi y Jigsaw comparten características debido a que tienen la misma meta que es modularizar, sin embargo OSGi es impulsado no solo para Java, tiene implementaciones para otros lenguajes de la plataforma .Net y Python, es así que parece ser que el proyecto Jigsaw pretende hacer más "simples" o "declarativas" las cosas para definir modulos dentro de Java, con lo poco que pude estudiar sobre OSGi lo único que me queda claro es que es bastante robusto pero a la vez también bastante complicado de entender e imaginó yo que esa fue una de las principales motivaciones para crear el proyecto Jigsaw y dejar de lado OSGi.

Lo de complicado de entender no lo digo yo solamente chequense aqui

También es cierto que OSGi ya tiene un uso extensivo por la comunidad y lo que me motivo a poner esta entrada de blog fue una presentación que encontre donde hablan de OSGi y Jigsaw asi como de un proyecto en donde pretenden que ambos coexistan, lo cual parece interesante para aquellos proyectos que se desarrollaron con alguna implementación de OSGi (Apache Felix, Equinox u otra) y se pueda migrar facilmente para convivir con otras que se desarrollen con Jigsaw, dicho proyecto es Penrose.

Espero sus comentarios y aportes de personas con más conocimiento de causa.

Saludos.