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/+.

My recently published SOA World article covering OSGi's state of art and future

SOA World recently published another article co-authored by me. In this article on OSGi, we, Dave Chappell and me, cover some basics of OSGi and discuss its relationship with other emerging technologies and frameworks like SCA, Spring, etc. We also cover some work in the area of distributed OSGi and future direction of OSGi.