Alex headshot

AlBlue’s Blog

Macs, Modularity and More

The rise and fall of OSGi and JSR277 (respectively)

2008, eclipse, java, jsr277, osgi

I had a lot of traffic generated from my InfoQ post on OSGi in the Enterprise (in which I echoed what everyone else has been saying during my absence) that if you want a kernel capable of modular development (whether dynamic or not), building upon OSGi is both the industry and the de facto standard. Of course, it might be a bit too low level for everyone, which is why systems like SpringSource DM Server are so important; to give people the benefits without forcing them to do things in an unfamiliar way.

As usual, there were comments and blog posts like “We should wait for a standard JCP to arrive”; which conveniently ignores the fact that OSGi was not only approved as JSR 291 two and a half years ago, but also as part of JSR 232 three years before that, and even one of the few single-digit JSRs JSR 8 back in 1999. So arguing against one particular JSR whilst promoting another JSR seems somewhat biased, to say the least.

It appears that I wasn’t the only person not posting either. I took a look at the JSR 277 list to find out what was happening, and the EDR2, promised in ’in a few weeks after JavaOne’ back in April, still has yet to materialise. In fact, it was followed up with a concern in June:

I am still waiting for EDR2 to become available. There are too many references to new EDR2 content to properly evaluate the somewhat thin OSGi interop proposal.

I have many issues with the interop proposal, but I can’t be sure understand the interop proposal until I have EDR2 in hand.

Now, a few months later on than that, there’s still no sign of the fabled EDR2. There was a glimmer of hope around JavaOne when Mandy Chung posted some items about OSGi interoperability, but that fell silent soon after.

It transpires that one of the reasons the traffic has fallen by the wayside was that Stanley Ho, the spec lead of JSR 277, was on his way out. In an announcement last month, he said goodbye to the list (although granted, he said “today is my final day” rather than “I’ll be leaving in a few weeks”; can’t really argue with missing that deadline).

This means that Alex Buckley, spec lead of JSR 294 “superpackages” and co-spec lead of JSR 277, will be taking over the reins.

So where will we go from here? Well, there’s been no traffic on the JSR 277 list for a month; it’s unclear as to how much of the EDR2 is ready from April or whether it’s been reworked continually since then. Alex did do some good cruft-culling in the JSR 294 spec, so maybe there’s hope yet for JSR 277.

Of course, it’s pretty moot at this point anyway. Over the years, Java has become more bloated and we’re not seeing any kind of modularisation of the Java VM like Harmony demonstrated. All we’ve got is a mini-bootstrapping device which lets you download cruft in the background so you can splash “Hello World!” faster. Applets were dead in 1998, and they’re still dead in 2008. For all the hype about JavaFX, Sun are still clinging to it like it makes a difference. .Net has won the windows desktop battle; but that’s not where the war is any more (and arguably hasn’t been for some time). Services (whether cloud or SOA), distributed communications (wide-area ZeroConf or Mesh) are where the money is these days. Even Eclipse RCP, a favourite of mne, hasn’t really done anything to dent .Net development; just go into any bookshop and count the number of .Net books for dummies vs the number of Eclipse RCP books for dummies. (Maybe there’s more .Net dummies out there? I guess it’s a self-fulfilling prophecy.)

Java will continue to survive - even if it’s in the form of source language only via Dalvik; but the JVM, if it could be pared down to the minimum, is still a great technology and opening it up for other languages (like Microsoft have done more successfully with the CLR) is the key to moving forwards. Scala has shown what you can do if you want to let the language evolve, but still has yet to penetrate mainstream in the way that Perl or Python have. Unfortunately, there’s too much reinventing the wheel going on in Java-land with not enough return on investment for the technology (though the return on lock-in is what it’s really about). Is it any wonder that JAVA has plummeted?