martes
ago142007
JSR-291 OSGi para J2SE
martes, agosto 14, 2007 at 7:05PM
Ha sido publicada la versión final del JSR-291 que define un framework para módulos o componentes dinámicos en J2SE. Esta propuesta es básicamente un intento de estandarizar OSGi en el Java Community Process.
OSGi es una especificación para un modelo de componentes dinámicos en Java, para dar un ejemplo, define un contenedor de componentes que permite instalar, desinstalar, actualizar, detener e iniciar un módulo (un jar) en tiempo de ejecución, así como definir sus dependencias con otros módulos y cambiarlas de forma dinámica en runtime. En pocas palabras, OSGi provee de un modelo mucho que el que brinda sistema actual de dependencias basados en JARs y de despliegue y actualización de aplicaciones estático existentes en Java; de ahí el apoyo que ha encontrado en la industria (Eclipse, BEA, IBM y Oracle lo usan) y también de ahí la necesidad de incluirlo de forma estándar en Java. Este JSR es el primer paso para lograrlo, sin embargo Sun no está muy convencida de OSGi y apoya el JSR-277 que define un modelo muy similar llamado Java Module System. El problema es que OSGi es el estándar de facto y ha ido evolucionando con el aporte y las experiencias de los usuarios, por lo que está en un punto en que resulta muy estable, por lo que no resulta lógico que Sun esté promoviendo una alternativa. Puedes encontrar más información sobre este debate aquí y aquí.
Sin ser sectarios, OSGi es una especificación mucho más madura y lista para usarse, Sun no tiene más que adoptarla. Este JSR es precisamente el primer paso para ello y se aplicaría a casi todas las versiones existentes de Java (de la 1.2 a la 6) mientras que el Java Module System se planea usar a partir de Java 7. Esperemos que Sun no se equivoque y otra ves estandarice sin oir a la industria y a los usuarios.
OSGi es una especificación para un modelo de componentes dinámicos en Java, para dar un ejemplo, define un contenedor de componentes que permite instalar, desinstalar, actualizar, detener e iniciar un módulo (un jar) en tiempo de ejecución, así como definir sus dependencias con otros módulos y cambiarlas de forma dinámica en runtime. En pocas palabras, OSGi provee de un modelo mucho que el que brinda sistema actual de dependencias basados en JARs y de despliegue y actualización de aplicaciones estático existentes en Java; de ahí el apoyo que ha encontrado en la industria (Eclipse, BEA, IBM y Oracle lo usan) y también de ahí la necesidad de incluirlo de forma estándar en Java. Este JSR es el primer paso para lograrlo, sin embargo Sun no está muy convencida de OSGi y apoya el JSR-277 que define un modelo muy similar llamado Java Module System. El problema es que OSGi es el estándar de facto y ha ido evolucionando con el aporte y las experiencias de los usuarios, por lo que está en un punto en que resulta muy estable, por lo que no resulta lógico que Sun esté promoviendo una alternativa. Puedes encontrar más información sobre este debate aquí y aquí.
Sin ser sectarios, OSGi es una especificación mucho más madura y lista para usarse, Sun no tiene más que adoptarla. Este JSR es precisamente el primer paso para ello y se aplicaría a casi todas las versiones existentes de Java (de la 1.2 a la 6) mientras que el Java Module System se planea usar a partir de Java 7. Esperemos que Sun no se equivoque y otra ves estandarice sin oir a la industria y a los usuarios.
in
j2se
j2se 
Reader Comments