Modular Swing Apps

Thanks to Colm Smyth for pointing out Jasper Potts' presentation from JavaOne on modularising Swing applications using a Spring-OSGi derivative known as SPAR. Nice to see OSGi being used by Sun.

OSGi the most important technology of the decade?

It may have been for me, but read the SD Times' view in OSGi Alliance Reaching Universal Middleware Goal.

JSR 291 Final Approval

JSR 291 just passed the Final Approval Ballot with twelve "yes" votes and two "no" votes.

Fourteen out of the sixteen Executive Committee members voted. The majority increased to ten compared to eight at the earlier ballots.

The positive comments praised the open approach of JSR 291, the suitability of the licenses, and the effectiveness of JSR 291 in influencing the other modularity JSRs. One comment urged JSR 277 and JSR 291 to become integrated, which will be achieved if JSR 277 delivers truly first class interoperation with JSR 291.

Voting comments from the detractors predictably concerned the work of the Expert Group rather than the underlying OSGi technology. They don't seem to like the JCP building on the work of other Java standards bodies. The concerns are discussed on the Expert Group mailing list and in an earlier blog.

I would like to express my thanks to many people who have contributed to the success of this JSR. They are too numerous to mention by name but include the JSR 291 Expert Group, the OSGi Alliance's Core Platform Expert Group, the Eclipse Equinox project, and numerous colleagues in IBM and elsewhere.

Designing module system interoperation

The various approaches to interoperation between JSR 277 and JSR 291 (OSGi) raise some interesting design considerations. The crucial distinction between these JSRs is that JSR 277 aims to be part of the Java 7 platform whereas JSR 291 is implemented as pure Java that will run on more or less any Java platform.

The JSR 277 Expert Group, or more accurately the spec. lead, is exploring the option of making some components such as the repository, module definition, and module instance pluggable and then having JSR 291 provide alternative implementations. This requires JSR 291 to surface its modules as JSR 277 modules, which will either require some generalisation of the notion of a JSR 277 module or a force fit. A force fit would probably result in unacceptable restrictions on interoperation and should be avoided.

A more ambitious approach, favoured by several Expert Group members including myself, is to rework JSR 277 to provide a 'custom module system' API analogous in concept to the way custom class loaders can be built on top of the existing class loader API. In this scheme, the JSR 277 module system would simply be the default module system packaged with the Java 7 platform and JSR 291 could implement its module system on top of the API. The challenge in this approach would be to design the API so that multiple module systems implemented to the API would naturally interoperate. A benefit of this design is that it would allow module system implementations to evolve faster than the underlying platform - something that JSR 277 doesn't yet enable its own module system to do.

A third approach, which I prototyped to prove that reasonable interoperation is achievable, involves a module system interoperation 'kernel' with which multiple module systems may register. Each module system provides a class, known as a 'wire factory' , for creating delegation paths ('wires') to its modules' class loaders.

One benefit of both the custom module system API and of the interoperation kernel is that they do not complicate the API that the module developer has to deal with. The 'plugin' approach requires generalisations of the concepts of repository, module, and module definition to be exposed on the module developer API. Although this kind of generalisation may actually improve the API, it could also end up making it more obscure. We'll have to wait and see.

Open Source Java at JavaOne

Much was made of OpenJDK at last week's JavaOne conference. On Tuesday morning, Rich Green delighted in telling the assembled masses "We are now, as regards the open-sourcing of Java, done" and then posted the following:

From: Rich Green  
To: announce@openjdk.java.net
Subject: Open JDK is here!

Today begins the next phase for Java. I am pleased to  announce that  
we have completed the open source release of Open JDK.
It's a great day for innovation - and remember, compatibility matters!
Rich

It turns out there is a bit more to do, like replacing some of the 'encumbered' code with a GPL version. Currently, the 6.5 MLOCs of OpenJDK source code must be built with some binaries which provide the encumbered code. Also OpenJDK doesn't yet build on Windows.

Sun have set up an Interim Governing Board to create a constituion for OpenJDK and to set up a proper Governing Board. The IGB has the following initial membership: Doug Lea, Fabiane Nardon, Dalibor Topić, and Sun's own Mark Reinhold and Simon Phipps.

The Apache Harmony technical session was well attended with more focus on the technology than on licensing issues and the JCK open letter.

Some anomalies still need working out. Sun said at JavaOne that it would release the JCK to the open source community, but later clarified that this meant the OpenJDK community. I guess that might even exclude forks of OpenJDK, but we'll have to wait and see.

Also, there is some strangeness in the way copyright assignment will be handled for eventual non-Sun committers to OpenJDK. The GNU definition of free software describes four freedoms including "The freedom to improve the program, and release your improvements to the public, so that the whole community benefits". So, in normal GPL projects, no-one has the right the make a fork without publishing their changes under the GPL.

Contrast this with the Apache license which allows anyone to create a fork and essentially do what they like with their changes, either publishing them or keeping them private.

OpenJDK is different from both these models. Sun, and only Sun, has the right to fork the code, make changes, and keep the changes private, although it seems unlikely that Sun would ever want to do that.

At this point when the source code is Sun's donation and when Sun is obliged to provide the source code to its licensees under the TLDA license, this is quite reasonable. But I wonder how many potential contributors will be happy to sign the Sun Contributor Agreement and give Sun these extended rights over their contributions.

Modularity at JavaOne

Modularity had a lot of focus at last week's JavaOne conference. There were multiple references to JSRs 277 and 294 by Sun speakers, specific technical sessions on these JSRs, and a combined JSR 277 and 294 BOF.

There were a number of questions and comments at the JSR 294 session on the strawman's structuring of superpackage membership information in a separate source file rather than distributed across the source files of the member classes. This is something we should discuss on the mailing list (which you can read via the observer list).

Apart from an OSGi Best Practices technical session and the JSR 291 BOF, there were several mentions of OSGi and JSR 291 in other sessions. The goal of interoperating well with JSR 291 was presented in the JSR 277 session and even mentioned in one of Sun's general sessions¹. Stanley Ho will float a proposal on the JSR 277 mailing list in due course, so subscribe to the observer list if you are interested (Expert Group discussions should begin to be mirrored there soon).

Ethan Nicholas gave an update on the browser edition work to minimise the download and initial install size of the JRE. This seems to be making good progress, although it is not based on any of the above JSRs, so there may be some 'shake-out' in due course.

In one of the "meet the team" sessions, I asked Sun's class library team what their plan was for exploiting JSR 277 and JSR 294 in the JRE. It seems they don't yet have one. I expect this to change, particularly after the JSR 277 and JSR 294 prototypes become available in a subproject of OpenJDK.

In contrast, the Apache Harmony session described how OSGi had been used from the start to modularise the class libraries. I gave a demo. of prototype JVM support for modular Harmony in the JSR 291 BOF.

GlassFish v3 is developing a module system known as HK2 ("Hundred Kilobytes Kernel") which is loosely based on JSR 277. It also has a dependency injection framework similar to Guice. (Unlike GlassFish which is mostly licensed under the CDDL, HK2 currently has no license defined, so you may want to avoid looking at the source code until there is a proper license.)

I had face to face meetings with Andreas Sterbenz to discuss aspects of JSR 294 and with Stanley Ho and Michał Cierniak to discuss interoperation of JSR 277 with JSR 291. There's a lot of work ahead and we won't know for quite a while how good the interoperation with JSR 291 will really be, but everyone concerned seems to be well aware of the importance of this capability.

1. See a couple of minutes from Intro. and Technical Deep Dive starting at 18 minutes and 45 seconds from the start when Danny Coward talks about modularity and refers to the goal of interoperation with OSGi.

JSR 291 Final Approval Ballot starts

The FAB for JSR 291 began today (Tuesday 8 May) - just in time for tomorrow's JSR 291 BOF session at JavaOne.

The Eve of JavaOne 2007

This week's JavaOne should be an interesting experience as it's my first.

After checking in this afternoon, I thought I'd sample James Gosling's session at the end of the Netbeans day. The content/time ratio was rather low, so I went for a walk in the daylight instead.

Perusing the pocket schedule in a Mexican restaurant later, I was pleased to see the JSR 291 BOF had made it into print, although it was too late for the IBM flyer. It seems like the BOF is competing with the tail end of the Eclipse party and Oracle's free screening of Spiderman 3. I'll be lucky if my co-presenter turns up (only kidding Richard).

The online session scheduler (JSP) seems to be struggling to stay up. How many thousands of people are hammering it? It finally let me switch a session.

Well, even blogging can't keep me awake. It's 9pm and 22.5 hours since I woke up. Better get to bed - tomorrow looks like a long day with sessions more or less continuously from 8.30am to 10.50pm. Boy do these American's take work seriously...

Harmony, Guice, and OSGi

I've recently been tinkering with Google's dependency injection framework, Guice, and getting a simple example to run under the Equinox OSGi framework. It was straightforward except that there are a couple of extra dependencies (i.e. that you couldn't infer from the source code of the example) that need to be expressed as imported/exported packages because of a code generation library, cglib, that Guice uses.

This morning, I thought I'd try running the example using the Apache Harmony JDK 5.0M1 and it ran cleanly first time. I'm very impressed since Guice makes extensive use of generics and annotations and cglib is hardly typical application code.

OSGi for application modularity

InfoQ published an article on why one company has decided to use OSGi, in conjunction with Spring, for application modularity.

They are not starting from scratch, so it will be interesting to see how pleased they are with the result. On the face of it, OSGi is a good match to their requirements, particularly for versioning and for deploying application updates without restarting the server.