Neil’s point-free blog

On 3rd December 2008, Sun announced that JSR 277 was — to all intents and purposes — dead, and that work on modularity would proceed under the new banner of “Project Jigsaw”. Furthermore, they promised to work entirely in the open and to co-operate with the OSGi Alliance in developing Jigsaw. This sounds great for those of us in the OSGi camp, and it could be a great opportunity to take OSGi to the next level, including modularisation of the Java runtime libraries and deeper integration with the Java language itself, the javac compiler and surrounding tools.

But, it could also turn out to be a total train-wreck. You see, the announcement, which appears here in Mark Reinhold’s blog, was very carefully and skilfully worded so as to promise very little while making Sun look like a great team player. But the actual outcome depends on Sun’s future behaviour.

Let’s look at what was announced a bit more closely. Jigsaw is supposedly a project for modularising the JRE itself, which is a very desirable goal, though one which Apache Harmony has already achieved. The first concrete item announced in the blog post is the death of JSR 277, or at least its suspension until after Java 7 (code-named “Godot”) arrives. There wasn’t much to love about 277 and most of the OSGi community either wished it would just die, or were working hard to try to fix its glaring flaws from the inside (like Brian Atsatt). So now it’s dead, surely the “just die” camp are happy?

Well, the one good thing about JSR 277 was that it was a JSR! As such, it was subject to the procedures of the Java Community Process (JCP), the most important of which being the ballot of the Executive Committee (EC), which every JSR must pass before it becomes an officially approved specification of the JCP. Not even Sun can force through a JSR against a majority of “no” votes in the EC, at least without unilaterally changing the rules of the JCP… and doing that would have shown up the whole JCP as a sham. So, if the final draft of JSR 277 had turned out anywhere near as awful as the first draft in October 2006, then the EC could have simply voted against it and that would be that. Let me just say that the OSGi community did not resist the creation of another module system because of fear or arrogance, but because we knew from long experience what a difficult and complicated task it would be. OSGi has been evolving and improving for ten years, and many lessons have been learned along the way. Invent something new if you must, but ignore the lessons of OSGi at your peril. JSR 277 seemed to go out of its way to ignore those lessons, shutting out OSGi experts and making technical decisions that were clearly doomed to failure. It’s fine to replace OSGi as long as you replace it with something better, but JSR 277 was going to be far worse.

Next, Mark goes on to explain that JSR 294 (the so-called “superpackages” JSR) will be revived. This JSR is all about support for modularity directly within the Java language, which is a relatively uncontroversial idea if done right. He then points out the success that OSGi has had in modularising Apache Harmony, but laments OSGi’s lack of integration with the Java language.

Now, it is not at all vital to have new keywords in the Java language in order to build modular applications today. Note that almost all of the J2EE application server vendors (including Sun itself) are either already building their servers in a modular fashion on top of OSGi, or are in the process of rebuilding them that way. Harmony shows that Java language support is also not a pre-requisite for building modular JREs. It would undoubtedly be a useful convenience to developers, as would enhancing the javac compiler to understand modularity better, but the absence of these conveniences is not a barrier to progress. Remember that, at Sun’s encouragement, more and more developers are using languages other than Java to build applications that run on the JRE. Some are using JRuby, a Sun-supported language project, others use Jython or Clojure or my own personal favourite, Scala. They can all use OSGi. So to discuss OSGi’s lack of Java language integration here seems like a distraction tactic. Nevertheless, Sun have promised to work with OSGi to make sure that OSGi can leverage the new language features when they become available, and that promise is very welcome.

Next Mark gets into the meat of the announcement about Jigsaw, and here I must quote him verbatim:

“This effort will, of necessity, create a simple, low-level module system whose design will be focused narrowly upon the goal of modularizing the JDK.”

“Of necessity”? What necessity is this? It is not explained either above or below. This seems like an appropriate time to point out that OSGi is also known as JSR 291 and is a fully approved official specification of the JCP. It should be the first choice when looking for a module system, unless there are sound technical reasons why it is inappropriate, in which case those reasons should be spelled out. Then the OSGi community could seeks ways to address those shortcomings, whatever they might be. There is certainly room for improvement in OSGi, but don’t simply replace it with something new (and probably inferior) just because it only does 98% of what you need.

Oh well, if Jigsaw is just an internal JRE thing then perhaps it’s not so bad… back to Mark:

“This module system will be available for developers to use in their own code, and will be fully supported by Sun…”

Right, so it’s NOT just an internal JRE thing. Developers of libraries and applications on top of the JRE will be encouraged by Sun to use Jigsaw. Presumably they will be encouraged to use it instead of OSGi, which sounds like a return to the bad old JSR 277… oh well, never fear, the Executive Committee will save us, won’t they? No, they won’t, because they can’t:

“…but it will not be an official part of the Java SE 7 Platform Specification and might not be supported by other SE 7 implementations.”

This work is being done outside of the JCP, so there will be no JSR for the Committee to vote on. Developers will be encouraged to use a proprietary module system cooked up by Sun rather than the JCP standard module system and if they do so they will be locked into just one Java implementation: Sun’s. The penultimate and final paragraphs attempt to put a positive spin on this bombshell, again I must quote them verbatim:

“In the meantime we’ll actively seek ways in which to interoperate with other module systems, and in particular with OSGi. All work on Project Jigsaw will be done completely in the open, in as transparent a manner as possible. We hope you’ll join us!”

This really goes to the heart of the problem. Yes, Java is (finally!) an open source project, OpenJDK, so any code that Sun checks into Project Jigsaw will immediately be visible to all who wish to see it. This is a huge improvement over JSR 277 where all of the work was done in secret. But there’s a big difference between open source and open governance. Sun employees constitute greater than 99% of the committers on OpenJDK, and any external committers are vetted by Sun and can be removed by Sun, so in practice no external parties will have the ability to significantly influence the direction of Jigsaw. A train-wreck happening in the open, and with no chance to stop it from happening, is still a train-wreck.

I don’t wish to be entirely negative. Jigsaw may be a great success, and Sun might actually keep their promise to work closely with OSGi. In my opinion the best way to interoperate with OSGi would be to simply use OSGi: they could use one of the existing open source implementations — they already employ the lead developer of one of them — or they could build a new implementation of their own. The specification is completely free and open for anyone to implement, and they certainly don’t lack the technical smarts to build an awesome implementation.

The future then is in Sun’s hands, for now the rest of us can only observe where they go with this. There is hope and opportunity in the Jigsaw announcement, but Sun has abused the trust of the OSGi community before so it’s naturally difficult to trust them now. However, I talked to Peter Kriens (the OSGi Alliance’s Director of Technology) and he said his plan is to work with Sun as closely as possible. Let’s call this his Sunshine Policy: by exposing Mark Reinhold and his team to OSGi as much as possible, he hopes to win them over. It could happen. Sunshine didn’t work for Kim Dae-jung, but it might for Peter… most developers I know have been won over by OSGi once they truly understood it.

Going back to the open governance question, I’d like to add my voice to the chorus calling for Java to be set free from Sun. A great analogy is with Eclipse: IBM released Eclipse as open source, but other vendors didn’t really get on board and build their own Eclipse-based tools until IBM spun it off as an independent entity. After that the ecosystem exploded (in a good way!), and created far more value for IBM than if they had held tightly onto the reins. And of course IBM is still very influential in that ecosystem although they hold no special status under the rules of the Eclipse Foundation. IBM is no altruist, they let Eclipse go for sound commercial reasons. Sun could do the same with Java, which I think would cause the Java ecosystem — already pretty huge — to expand to absolutely insane proportions.

Now, Mark, wouldn’t that be cool?