Update: Alex Buckley has posted on the modularity observer mailing list that any JSR which doesn’t post an EDR is automatically filed as inactive. We await a new EDR to celebrate its resurrection. Below is the original post.
As my Bundle.update: OSGi in Java EE and JSR 294 marked inactive post on InfoQ noted, JSR 294 is now marked as ‘inactive’ on the JCP.
This brings both Sun-sponsored efforts on Java modularity to a formal close, leaving JSR 291, aka OSGi 4.1, as the current officially approved spec for Java modularity.
There hasn’t been much traffic on the JSR 294 mailing list for a while; the Simple Module System proposal was a last ditch effort by members of the JSR 294 Expert Group to bring some kind of sanity to the module process, even offering olive branches to try and overcome the (perceived) problems.
There were really two main sticking points that prevented a common modularity story happening:
- The format (and semantics) of the version number were inconsistent between the de-facto standard OSGi and the proposed “Vaguely Debian-like versions” – despite everyone in the industry using three digits or less for component versions (and not marketing versions, as I’ve noted before). Stanley Ho’s notable Minor version number should be incremented for making medium or minor changes where the software remains largely backward-compatible sums up the approach nicely here; specifically, that there’s no understanding of how to do versioning properly.
- Confusion about bundles vs JARs vs split packages; OSGi supports all of these, despite fears to the contrary. And although there are a number of (somewhat hairy) inter-dependency problems between Java’s packages, Apache Harmony shows that not only can it be done, it can be done under the same OSGi semantics. It’s worth explicitly noting that Harmony doesn’t need (or provide) an OSGi runtime; yet it adopts the same semantics in the individual modules manifests with a custom (non-OSGi) checker to verify that the constraints hold.
The Simple Module System was really the last ditch attempt by the expert group to save compatibility between Sun’s JDK modularisation attempt Jigsaw and the de-facto modularisation standard that everybody uses. Even if Jigsaw is a resounding success, it still won’t be available until after Summer 2011, and that’s assuming that a JSR for Java 7 ever materialises – which according to sources, is unlikely to happen any time soon.
Q Why not start a closures JSR now and let its Expert Group do the work of formulating a new proposal?
A For the same reason that there’s not yet a JSR for Project Coin, namely that no new Java SE JSR is likely to be approved until the present dispute in the JCP Executive Committee is resolved.
final message to the JSR 294 group directed all Jigsaw-related traffic to the project Jigsaw mailing list. It appears that rather than trying to build consensus amongst the expert group, they’re leaving it to the implementation of Jigsaw to drive the standard – and presumably, whatever “Vaguely Debian-like semantics” actually means. Still, whatever happens, we can agree that modularisation of the JDK is still a laudable goal, and that Jigsaw, as a Sun-specific JVM implementation detail, is likely to be well honed for that purpose; but nothing else.
Meanwhile, OSGi goes from strength to strength (see my state of OSGi posts at InfoQ columns in December and October 2009), with all major JEE vendors using or providing OSGi runtimes, including Sun’s recently released GlassFish v3. The ongoing work of the OSGi Enterprise Expert Group is likely to make the future JEE specifications irrelevant in any case; adopters will simply be able to assemble their own runtimes based on OSGi and however large or small the components are to support their needs. It’s unlikely that we’re ever going to see a new JEE JSR, although it’s likely that individual specifications (Servlet, JSP, etc.) will continue to evolve independently as now.
At the moment, there’s very few developers who aren’t aware of OSGi; and aside from a few disgruntled NetBeans users, who insist on believing
OSGi == Eclipse == IBM (here’s a hint; the developers of the Apache Felix OSGi runtime – which includes Sun employees – all use NetBeans), developer tools (Eclipse, IntelliJ) and build environments (Maven/Tycho, PAX Construct) are already here. And even though Maven 3 is just around the corner, the next version will be based on an OSGi runtime and adopt OSGi version number semantics.
So, compatibility between Jigsaw and OSGi is not going to happen. The choice is simple; if you’re writing the JDK, use Jigsaw. For everything else, there’s OSGi.