When I use a word, it means just what I choose it to mean - neither more nor less.

It's scary to look back and see how long it is since I last wrote in this blog. Time flies by so quickly, and since I last wrote I've been lucky enough to organize an internal company conference in Toronto on open source software, present at EclipseCon in Santa Clara, and present at JavaOne in San Francisco - where there was a strong theme around OpenJDK.

I like to think that I follow the open source JSE community reasonably closely, but I'm confused about the 'message' coming from Sun and the reality of what is happening. For example, in the opening keynote at JavaOne Rich Green (Executive VP Software), talking about the open sourcing of Java, announced "the completion of that task"; whereas the technical sessions delivered by the troops on the ground clearly show there is lots of work to do in opening the full codebase, defining the governance model, building the community, and so on. There are numerous tricky problems outstanding and I think the executives do the team no favours by these sound-bite announcements.

One issue that has been picked up by a few people is the dependency on Apache licensed libraries in OpenJDK. It would seem that the weasel words are being polished to explain how it is ok to continue the dependency between ALv2 and GPLv2 code, because OpenJDK is Sun's code and they get to play the Classpath exception as they see fit. I said, as they see fit deliberately.

The Classpath exception allows applications to run on the JRE without considering the application to be covered by the so-called viral effects of the GPLv2 as the VM links the class files into a single runnable system. Sun declare, understandably, that the Classpath exception applies to the public API and SPI only, i.e. those places where an end user is expected to call or extend the standard runtime. How then can this same exception be used to justify embedding differently licensed parts of the class library that they are missing? What makes those parts of the implementation special to an end user? Some ALv2 libraries, like BCEL are very low-level, bit-twiddling operations that form core parts of the runtime by any reasonable definition.

Sun are on a journey, I'm supportive of their efforts to change. There are enourmous hurdles to overcome based on the history and inertia of the existing in-house development effort, and I certainly am not going to stand at the side throwing stones as they change that. It's tough.

One jaw-dropping moment for me occurred during the open source panel discussion at JavaOne, when Tom Tromey declared that he sees no value in GCJ/Classpath beyond OpenJDK worth the investment from Red Hat, and that a single implementation of the specification is preferable. I deeply disagree with this view. What is the purpose of a specification if there is only one implementation? -- by definition, the specification would become "whatever the implementation does". Perhaps Tom would be happier if there was only one Linux distro too. How about we all agree that SUSE wins, and Red Hat and others can contribute there?

Java gets used in so many places, there is room for multiple implementations with different characteristics and target audiences. Of course, the spec should restrict the madness, and foster common criteria that make the runtime usable (clutch on the left, brake in the middle and accelerator on the right etc.). The JCP is established to evolve the specification, but there is plenty of scope for competition to drive innovation and enhancements in the platform within that remit.

So why does Sun continue to block Apache Harmony from demonstrating their compatibility with the spec through the JCK? Well it is a mystery to me. I'd have thought that encouraging implementations to be compliant rather than forcing them to produce look-alikes would be of benefit to the Java ecosystem. Certainly the people who contribute to the evolution of Java through the JCP seem to expect that.

I hope to reduce my conference-going over the next few months, and get back to the code. Its a joy to watch the Harmony project continually move at the speed of the quickest person. When I'm away for two weeks there is a load of mail to read, commits to review, new docs to review, and progress to catch up on. I'm happy we are not delivering sound-bites.