The debate over JSR 277 (Java Module System) and OSGi (JSR 291) is picking up steam again, with the JSR 316 (Java EE 6) submission restarting the previous debate about the overlap between OSGi and JSR 277.
Peter Kriens posted a blog entry in which he discusses the use of profiles for Java EE 6, and presents componentization as an alternative basis for Java EE 6. Kriens also questioned the use of JSR 277 in the Java EE 6 specification, saying:
JSR 316 only mentions JSR 277 in the specification request, in a rather indirect way. They basically say that 277 is coming and they'll defer any decisions until it is there. Seems fair because 277 is older and more mature than 291 looking at their numbers? Well, except for the fact that 277 is still in draft review and 291 is already final because 291 could be based on the very mature specification that originated in 1999 and has gone through 4 major revisions. So there must be another reason why JSR 291 is not mentioned? Maybe 277 will provide features that JSR 291 does not have? Hmm, not really. Looking at the JSR 277 specification request one can not claim that the ambition level is high in comparison to JSR 291/OSGi: no dynamics, no class space consistency, no unloading, no package imports, etc. Their early draft was still on a rather simplistic level. The only real addition over 291 is the repository and there are many loose ends. JSR 277 recently opened up the mailing list, taking a look at the discussions it seems that they are still struggling with some of the basics of modularity. However, fortunately, the JSR 277 expert group has promised to make the 277 module system interoperate with JSR 291/OSGi. That makes choosing OSGi risk free as well as providing the additional benefit of running today on a wide range of VMs (from 1.2 to 6, also in embedded devices), unlike JSR 277 that will only run on Java 7 when it comes out late 2008. So why should JSR 316 wait? The perfect solution exists today and is promised by JSR 277 to be compatible with tomorrow?
Alex Blewitt also questions the Java EE 6 decision to use JSR 277:
The submission states:To better support the extensibility goals of the platform it would be useful to have a more general concept of modules. Such work is underway in JSR-277 - Java Module System, which is targeted for Java SE 7. We anticipate that Java EE 7 will build on that technology and thus we will defer specification of any potentially conflicting technology to a future release .In other words, they've chosen JSR 277 over JSR 291, and refuse to consider anything else until after JSR 277 has been released in Java 7.
Eric Newcomer was also asked by InfoQ whether he thought Sun should adopt OSGi:
Absolutely, would make all the sense in the world. The bigger question is around the future of Java, and whether or not Sun will embrace OSGi or continue to fight it, and if they do continue to fight OSGi what impact that will have on Java. From my recent and somewhat limited experience with OSGi it seems that it significantly improves Java in many ways – modularity, versioning, improved class loading.
Sun voted against JSR 291, which passed anyway, making OSGi officially part of JSE. But that gives some indication of Sun's view. Sun has also proposed JSR 277, for Java modularity, which appears to significantly overlap with OSGi. Sun has a great opportunity to embrace OSGi and base Java 7 on it, but even though there is no official statement it seems that they are leaning in the direction of overlapping rather than embracing OSGi.
I hope Sun comes to their senses about OSGi sooner rather than later. On the other hand, perhaps it would be better if Sun continues to oppose OSGi, since things have gone well for OSGi so far.
Hani Suleiman, a member of the JCP Java SE/EE Executive Committee, has a different viewpoint on the debate. In response to a question about a common ground between JSR 277 and OSGi, he said:
[...] JSR-277 is (sort of) that common ground. It attacks the problem from the JDK side, making life much easier for OSGi and other such solutions (maven, ivy, etc). Bundles/modules become first class citizens on the JVM level.
Beyond that, it’s up to the framework (OSGi or whatever else) to provide any value-add stuff they want to. 277 does not limit that. The OSGi people just get upset that the standard baseline is not their implementation, and actually takes other things into consideration.
In terms of the Hibernate analogy, imagine if JBoss kept attacking the JPA spec, saying it’s reinventing the wheel and everyone should just standardise on Hibernate instead. That’s what the OSGi people are doing.
Others, such as Neil Bartlett, have raised concerns about the JSR 277 expert group discussions:
Take a look at the expert group mailing list for JSR 277, which is now open to the public (albeit read-only). Having done so, it's really hard to see that the two OSGi experts (Glyn Normington and Richard Hall) are being listened to. It's certainly not from a lack of effort on their behalf. There are numerous areas in the JSR 277 draft spec and the current strawman which are irreconcilable with OSGi: Sun is willfully refusing to learn any lessons from the experiences of OSGi/JSR 291.
OSGi people are not simply complaining because our favourite module system has not been chosen. That would be childish. The principle reason that we are making so much noise is that JSR 277 is heading towards failure as a module system! It will be hugely damaging to the entire Java community to have a broken module system baked into the JVM.
Another perspective on the origins of the debate was offered by Chris Custine:
I think the big conflict between Sun and OSGi is a very simple political battle over control and licensing. Technology be damned! Once again the politics of Java are eschewing the common sense and logic that would normally prevail among intelligent individuals. I have been very hopeful that Java was making a resurgence in its ability to innovate and evolve, but this is the kind of thing that makes me worry...Glyn Normington, a member of the JSR 277 expert group and specification lead for JSR 291, has tried to present a more measured opinion on the debate. In addition to a feature comparison, Normington has also written a detailed overview of the issues surrounding this debate. He notes that "the goals of these JSRs are rather different, although the underlying concepts are similar. JSRs 277 and 294 are building basic support into the Java SE platform whereas JSR 291 is pure Java built on top of the Java platform". Normington states that reusing OSGi in JSR 277 is not straightforward, and also discusses and dismisses the idea of discarding JSR 277, before coming to his preferred resolution:
The dream solution is clear: JSR 277 should adopt JSR 291, underpinned by language and VM support in JSR 294, and add the JSR 277 repository architecture. This would accelerate the progress of JSR 277 by several years and guarantee perfect interoperation between JSR 277 and JSR 291.
But it would take a complete about turn by Sun to turn this dream into reality. Maybe, just maybe, Sun are sufficiently committed to the success of Java that they will eventually decide to do just that. Maybe, just maybe, the Java community will be able to look back later and paraphrase Winston Churchill: "Sun could always be counted on to do the right thing, after having exhausted all the alternatives".
There is definitely a lot of debate in the community about what the best solution to this quandary is - what do you think?