Glyn Normington has worked on both the Core Platform Expert Group of the OSGi Alliance and in the Java Community Process as spec lead, so he definitely knows his way around both. In this blog entry, he breaks down the main issues surrounding Java modularity, OSGi and JSR's.
I think of OSGi as being the pinnacle of custom class loader systems. The way it manages to install, uninstall, start, stop, and update modules without restarting the VM is quite an achievement - not my achievement, I should add, as the dynamic features were mostly complete before I got involved. Of course, other systems have provided some of this capability, but not in such a generally reusable way.
Why doesn't JSR 277 (The Java Module System) reuse OSGi? So why can't the JCP simply adopt JSR 291(Dynamic Component Support for Java SE) as a standard module system for the Java platform? That's what many of the critics of JSR 277(The Java Module System) are calling for. A crucial issue is one of control. I hope the OSGi Alliance would allow OSGi to be included in the Java platform so long as they retained control of the technology. But I suspect Sun would be nervous about the core module system of the Java platform not being under their direct control. Such nervousness would be understandable if it was not in the interests of the OSGi Alliance to maintain the value of Java, but the reality is just opposite: the success of the OSGi Alliance depends to a large extent on the success of Java.
Read the complete post : Java modularity: where do we go from here?