OSGi and JSRs
We did not want to elaborate on issues between JSRs and OSGi in a recently published article.
OSGi specification started with JSR-8 which was intended to be based on Sun’s Java Embedded Services 1.0. However when the JSR-8 was withdrawn And the work was carried out by OSGi,a non-profit alliance. Over a period of time, OSGi’s work directly or indirectly influenced many of the JSRs (e.g. 232, 239, 246 (Mobile Specs)) and thus J2ME. However, OSGi and JSRs have not always been in good friendship. For example, Sun introduced JSR-277 to define a competing (overlaps in packaging/deployment but differs in dynamics/lifecycle) model to provide a new distribution format, a repository, discovery, loading, and integrity mechanisms at runtime. Though a couple of OSGi folks were members of this JSR-277, this JSR largely was viewed by OSGi community as an act of ignoring their 8 years of experience. In contrast to JSR-277, the recently approved JSR-291 for Dynamic Component support is a direct adoption of OSGi’s R4 specification. Similarly JSR-294 would add a VM level modularity support in Java 7. However, the recently introduced JSR-316 for J2EE 6 defers the adoption of JSR-277 and does not comment on adoption of JSR-291. Similarly, a JSR for JBI 2.0 (JSR-312) acknowledges a need to add OSGi features but stays away from embracing it (Specific comments: “Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.”). I hope that future releases of J2SE / J2EE does directly adopt OSGi R4/+.
OSGi specification started with JSR-8 which was intended to be based on Sun’s Java Embedded Services 1.0. However when the JSR-8 was withdrawn And the work was carried out by OSGi,a non-profit alliance. Over a period of time, OSGi’s work directly or indirectly influenced many of the JSRs (e.g. 232, 239, 246 (Mobile Specs)) and thus J2ME. However, OSGi and JSRs have not always been in good friendship. For example, Sun introduced JSR-277 to define a competing (overlaps in packaging/deployment but differs in dynamics/lifecycle) model to provide a new distribution format, a repository, discovery, loading, and integrity mechanisms at runtime. Though a couple of OSGi folks were members of this JSR-277, this JSR largely was viewed by OSGi community as an act of ignoring their 8 years of experience. In contrast to JSR-277, the recently approved JSR-291 for Dynamic Component support is a direct adoption of OSGi’s R4 specification. Similarly JSR-294 would add a VM level modularity support in Java 7. However, the recently introduced JSR-316 for J2EE 6 defers the adoption of JSR-277 and does not comment on adoption of JSR-291. Similarly, a JSR for JBI 2.0 (JSR-312) acknowledges a need to add OSGi features but stays away from embracing it (Specific comments: “Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.”). I hope that future releases of J2SE / J2EE does directly adopt OSGi R4/+.
posted by Khanderao at
5:53 PM
1 Comments:
Hello. This post is likeable, and your blog is very interesting, congratulations :-). I will add in my blogroll =). If possible gives a last there on my blog, it is about the Dieta, I hope you enjoy. The address is http://dieta-brasil.blogspot.com. A hug.
By
Anonymous, at 2:11 AM
Post a Comment
<< Home