Neil’s point-free blog

This Monday at EclipseCon I delivered a tutorial along with my colleague Heiko Seeberger on component models used in OSGi service programming. Our aim was to explain and compare three of the more popular component modes: Declarative Services (DS) , Spring Dynamic Modules (DM), and Apache iPOJO. The slides follow at the bottom of the post as an embedded SlideShare presentation. The example code is available on GitHub at http://github.com/njbartlett/eclipsecon09_components/. Inside the project you can also find the slides in PDF format. Both the slides and code are released under the Eclipse Public Licence.

This week at EclipseCon I have had the pleasure of meeting Alex Buckley, Sun’s Java language supremo and spec lead for JSR 294. For those of you who do not memorise JSR numbers, 294 was originally known as “superpackages”, was killed off for a while, and is now back in the form of enhancements to the Java language to support modularity. As an OSGi supporter I have no problem in principle with JSR 294, indeed it may make the use of OSGi easier, especially for beginners learning the Java language.

However, authors of libraries and applications should not have to choose which of two module systems to support when they release their software to the world. Another Sun project named Jigsaw aims to build an alternative module system to OSGi, one which will be built into OpenJDK and available for library and application developers to use. For a large number of Java developers, the convenience of using Jigsaw is likely to trump any arguments about the technical superiority of OSGi, as OSGi must be downloaded separately. Mark Reinhold announced in his blog that Jigsaw will be fully supported by Sun, although it is not an official Java standard backed by a JSR.

Time for some commercial reality. Yes, Sun is the “mothership” (as Alex puts it) for Java right now, but Sun is unlikely still to exist in its current form by this time next year. Whether it is eaten whole by IBM or torn in half and shared between HP and Oracle, or any of the other rumoured outcomes, a promise from Sun to support Jigsaw is completely worthless. This is especially true because Jigsaw is in direct opposition to the commercial needs of all the potential acquirers. If IBM gets Java, it will kill Jigsaw, I guarantee it. Ditto Oracle. By choosing to build Jigsaw outside of a JSR and in opposition to an established industry standard, Sun has exposed its customers to substantial commercial risk.

I don’t like making the argument against Jigsaw this way. I would much rather debate the relative technical merits versus OSGi, but I feel I have already done so and the OSGi community continues to do so. However Sun intends to use its commercial power as the owners of the predominant Java distribution to force through Jigsaw irrespective of its technical merits, therefore I believe it is not inappropriate to counter with commercial arguments in addition to technical ones.

So as a Java developer interested in modularity, you now have a choice. Do you choose OSGi, an industry standard supported by an alliance of over 30 companies, two JSR numbers and over ten years’ experience? Or do you choose Jigsaw, a new proprietary platform supported by one vendor on the brink of acquisition/bankruptcy? Your job may depend on the answer.

On the 14th April I will begin teaching the first in a series of OSGi training courses, in association with SkillsMatter in London. This is a really in-depth course that explores the fundamentals of building modular applications with OSGi. Then after getting to grips with modularity we will tackle component-oriented development with OSGi’s dynamic services.

In my opinion OSGi is going to be extremely important for the future of the Java platform, and this course will teach a highly pragmatic approach to adopting it. This includes a review of build tools, testing techniques, and how to use OSGi in “legacy” applications.

The first run of the course is heavily discounted — if you book early you can get 50% off the full price. If you can’t make the April run then subsequent runs will happen in June and September, and for those not in the UK there are plans to teach the course in several other European cities this year also.

Please see the SkillsMatter course page for full details and booking information.

S3Install is a very simple runtime OSGi bundle for provisioning an Amazon EC2 node. It is modelled on the FileInstall bundle by Peter Kriens, but instead of monitoring a local directory it monitors an S3 “bucket”. So, you can drop a bundle JAR into S3 and the OSGi runtime will install and run it. Drop in an updated version and the runtime will update to that version on the fly. Delete the JAR from S3 and the corresponding bundle will be uninstalled from the runtime.

Although simplistic, this approach should scale very well. Whether you have one EC2 node or thousands, you can roll out new and updated application code simply by uploading a file with your favourite S3 client. Assuming all the nodes are running an OSGi framework plus S3Install, they will automatically update themselves.

This is very much “Poor Man’s Provisioning” at the moment. The Rolls Royce of provisioning is probably Newton from Paremus, but I think it makes sense to start with a simple approach and add complexity only when needed.

The code along with some instructions are at GitHub, please try it out and let me know if it works for you and what features could be added. Features I’m already planning to add include support for Configuration Admin (like FileInstall), and support for E4 JavaScript bundles.