JSR 291 passes by a landslide
As you may have noticed, EclipseZone has had a few problems recently with posts not making it through to the newsgroups (and vice versa). We think we've nailed that problem on the head, so posts should be getting through now. We've also had a few glitches where posts would appear to be duplicated; hopefully that's been resolved as well. It seems that we're not the only ones that have had problems; Eclipse.org has suffered an uncharacteristic failure last week too. Let's hope that February is better for both of us, and able to cope with the load in March! We've also been working on a new look for EclipseZone. You can preview the new look at eclipse.dzone.com; in addition, we'll be adding a news feed for the newsletter too. Let us know what you think of it! It's been a pretty eventful couple of weeks. Recently, JSR 291 passed the public review stage; for those that don't know, it's the JSR ratification of the OSGi 4.1 service release. Whilst it's been argued by some that rubber-stamping the existing OSGi spec may not add much, in fact there have been some notable changes to OSGi 4.1 that have evolved from the working groups. In particular, bundles can be started 'transiently' i.e. they do not automatically start on the next platform restart. The benefits of being part of the JSR process will also help users of OSGi; as the comment from Apache shows, there's still some work to open up the licensing of the spec, and hopefully the involvement with the JSR process will help that. Being (predictably) one of the no voters, Sun is betting on the JSR 277 horse instead. Some might argue that it's a mule, rather than a horse; for example, it doesn't have the concept of separate classloaders which gives the OSGi platform the ability to bounce bundles at run-time. I personally think it's quite likely that Sun will railroad JSR 277 into Java 7, in much the same way that it railroaded the logging packages in (and with much the same effect). However, the result of the OSGi JSR is unlikely to mandate that it is bundled with the core Java libraries; instead, it's going to provide a more formalised reference specification as well as testing compatibility kit for open implementers to use. This is actually a good thing; as Peter noted on the OSGi blog recently, Java has become fat and bloated over the years. That's one of the reasons behind Steve Jobs' rationale of not having Java on the iPhone. What's really needed is a fresh approach; by reducing the VM to a kernel that can then have bundles attached, you can have a much more modular system and include what you want without the cruft. In fact, that's exactly the approach that Harmony is taking; a core JavaVM kernel, and many individual bundles providing distinct units of functionality (IO, Net, AWT etc.). Perhaps when the Sun VM and libraries are fully GPL'd, we'll see innovative approaches there too (though you won't be able to call it Java TM). Meanwhile, work continues furiously on the Eclipse platform, with large numbers of bugs being closed daily. We're nearly at 3.3M5; by the time you get the next EclipseZone newsletter, you should have been able to download it. There should also be plenty more examples of the new Menu item placement structure; if you've got plugins that you want to migrate towards 3.3, then this is something you need to start looking into now. The nominations for the Eclipse awards have now closed (and thanks for whoever nominated me for top ambassador :-) Voting will run for three weeks until February 16th, with the winners announced at EclipseCon. We'll be running profiles over the next week at EclipseZone's front page so if you don't know the nominees, you can find out about them before voting. It's a great way to recognise the people who contribute towards the Eclipse community and codebase; you might want to wait until you've read the profiles before making your mind up! But don't forget to vote before February 16th, when voting closes. Lastly, EclipseCon is filling up fast; early registration (which gives over 15% discount off the full price) closes in a couple of weeks (February 14th), so if you want to save money, you should register soon. Last year, EclipseCon sold out well before the conference, and given the rise in traffic and usage of Eclipse RCP, combined with the co-hosting of the OSGi developer conference, means that it's likely to sell out sometime in February this year. If you want to guarantee a place, register now and we'll see you there!
Until Next Time,
Alex Blewitt
alex@eclipsezone.com
|