I think there are lots of politics involved. Peter Kriens, OSGi spec
author, evangelist and old timer was rejected to become a member of
JSR277, and is upset about it:
http://www.aqute.biz/2006/02/osgi-and-jsr-277-bad-vibes.html, (he have
written a number of times about it on his blog).
Interesting enough Richard Hall, Felix lead and OSGi member, is part of
both JSRs.
All the issues with OSGi listed in the citation from JSR 277 are solved
in OSGi R4.
IBM seem to make a huge investment in OSGi while Sun doesn't, so I
wouldn't be surprised if this is part of there fighting as well.
Anyway, standardized Java modularization is needed now, so waiting to
Java 7, seem less attractive.
/Daniel
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Apache and some other well known organizations have started an JSR
for dynamic component framework in Java SE based on OSGi.
http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html
http://www.jcp.org/en/jsr/detail?id=291
4 months to get a JSR out of the door? whatever.
This seems a rushed up battle against JSR 277, which states:
The current version of the Open Services Gateway Initiative (OSGi)
specification defines a framework that enables the deployment of
service-oriented applications (called bundles). However, the framework
only supports package dependency based on the minimum version of a
specification, and there is no support for exact version or version
range. The framework also supports package dependency based on an
implementation, but there is no support for versioning. Moreover, the
framework must choose one bundle that will be the provider of the
exported package for all bundles which have dependencies on that
package, so it is impossible to support more than one version of
shared package at runtime. Besides, the selection of exported package
provider is anonymous, and there is no way to influence the selection.
Because the versioning semantics in the OSGi framework is simplistic,
it is not a sufficient solution to address the JAR referencing problem.
While JSR 291 states:
No current JSR (either complete or in process) defines a dynamic
component and lifecycle solution to run on top of the existing family
of Java SE platforms. However, JSR 232 does include this capability to
run on top of Java ME (CDC based platforms) along with a comprehensive
set of mobility services.
JSR 277 has been filed to examine changes to the static module
definition to be used within the Java SE platform for Java 7 (Dolphin)
and beyond. JSR 277 is targeted for specification delivery in 2H/2007
with RI/TCK delivery as an integral part of Dolphin in 2008.
This JSR aims to address the current needs for dynamic components
based on existing Java SE platforms. When Dolphin becomes available,
the specification lead of this JSR will either perform a maintenance
release of this JSR or raise a follow on JSR to add Dolphin to the
list of compatible supported platforms and to exploit Dolphin
technology for static modules, as appropriate.
These two JSRs are heading on a massive collision course.
