Fin de la polémica entre OSGi, Jigsaw y el JSR 294

OSGi (inicialmente las siglas de Open Services Gateway Initiative, aunque ahora ya sólo son "OSGI") es un grupo de estándares que han definido un modelo de componentes modulares que definen el ciclo de vida de los componentes, proporciona un registro para ellos y proporciona un entorno de ejecución. Se trata de una tecnología muy madura y probada en la cual se basa, entre otros muchos, Eclipse.

El JSR 294 tiene como propósito mejorar el soporte para modularidad dentro de la plataforma Java. Su propósito es que sea posible distribuir tanto la máquina virtual, como las librerías estándar, como tu propia aplicación en módulos que puedan descargarse bajo demanda y que se integren adecuadamente con los mecanismos de gestión de aplicaciones nativas. Una de sus ventajas, al modularizar la máquina virtual y las librerías estándar, será una mayor velocidad de arranque de la máquina virtual al tener un control más fino sobre qué es necesario cargar y qué no. Ahora mismo, Sun considera esto como crítico para su negocio, para conseguir que JavaFX sea realmente competitivo con otras alternativas como Flash, que en la actualidad resultan mucho más "ligeras".

Jigsaw podría considerarse como la implementación del JSR 294 que Sun está creando para su JDK 7.

Terminadas las presentaciones, pasemos al motivo de la polémica. Desde el campo de OSGI se ve con buenos ojos al JSR 294, pero se critica que su implementación (Jigsaw) no se base en OSGI. Esto ha dado lugar a una "guerra" entre los defensores de OSGI y Sun; los primeros acusan a Sun de querer reinventar la rueda y de no basarse en una tecnología ya probada.

Este ya viejo debate se ha reavivado recientemente por las (bastante poco acertadas) palabras de Gosling donde afirma que el problema con OSGI es que es demasiado pesado, y que Jigsaw hará lo mismo que OSGI, pero será más ligero. Esto no es correcto del todo.

Recientemente Javaposse ha entrevistado a Mark Reinhold, Chief Engineer de Java 2 SE, sobre este tema. De todo lo que he leído sobre la polémica entre OSGi y Jigsaw, esta entrevista es de lo mejor. En ella se explica claramente que OSGI y jigsaw se solapan, pero no completamente. El primero hace muchas cosas que Jigsaw no necesita. Y el segundo necesita varias cosas que no están contempladas en OSGI. 

Dos ejemplos concretos son la necesidad de cargar en un mismo cargador de clases dos clases que pertenezcan a módulos diferentes pero estén dentro de un mismo paquete Java (necesario para modularizar las librerías estándar). Otro problema de OSGI es que no se integra bien con los sistemas de gestión de paquetes de los sistemas operativos (necesario para mejorar la integración de las aplicaciones Java con los sistemas operativos). Por otro lado, hay cosas que aunque con OSGI son factibles, pero muy complicadas, como por ejemplo que el compilador explote la información relativa a los módulos en tiempo de compilación.

En la entrevista Mark Reinhold afirma que el único motivo por el cual están construyendo Jigsaw es porque no les queda más remedio, y que si OSGI les sirviese por supuesto que lo habrían utilizado, del mismo modo que los desarrolladores de Glasfish decidieron que OSGI era precisamente lo que necesitaban para el servidor de aplicaciones.

Definitivamente recomiendo el podcast a todos los interesados en este tema. Y, desde mi punto de vista, esta entrevista zanja definitivamente la polémica OSGi vs Jigsaw.