Moving Java forward through the JCP?

Mark Reinhold recently pointed out that he, Joe Darcy and Brian Goetz had submitted their OpenJDK work on features for JDK7 and JDK8 to the JCP for standardization. Normally I am somewhat sceptical about the JCP. I don’t believe the JCP fosters a truly open process and discourages Free Software implementations. But Mark, Joe and Brian seem to be proving me wrong. Of course that shouldn’t have surprised me, since they have shown themselves to do everything in the open and actively involve the community in all their OpenJDK work. All their code has been published under the GPL for everyone’s free use.

The JSRs mention that the code for the Reference Implementation will be developed within the OpenJDK Community. Mark has kept the JDK7 planning page and features page public and up to date. And all (prototype) code of the various proposed JSR components is already available under the GPL. People who have been following the various OpenJDK mailinglists know that they have also already announced that they will keep using the existing OpenJDK repositories for developing the Reference Implementation and they look forward to continued collaboration with the community through those same open public mailinglists.

So these might well be the most open, public and free java platform JSRs out there. Now the Free Software implementation defined through the community in OpenJDK comes first, and then gets standardized through the JCP. That seems a very good thing.

There are however still some small issues that in my humble opinion make this standardization effort less effective than could be. That mainly comes from some of the legalese included in these JSR proposals. The legal language used seems to not have caught up with the new OpenJDK reality yet. This might lead to the schizophrenic situation that the community that helps and takes advantage of the fact that we now collaborate in the open might not actually be able to use the results of this standardization process to check their own implementations are according to the official specification because the current terms seem incompatible with the terms of the GNU General Public License used for OpenJDK, IcedTea and other community derivatives of the code that implements the reference implementation.

Firstly the proposed specification license is tightly coupled with (passing) the TCK (which has its own problems, see the last point below) and contains restrictions, specifically on sub and super setting, which are incompatible with the GPL. But since most of the specification, like those for the full class library are also published under the GPL (just do a yum install java-1.6.0-openjdk-javadoc), such restrictions on the official final specification license are counter productive and conflict with the actual implementation license used for OpenJDK. Secondly the proposed reference implementation license is still proprietary. As I pointed out before, this prevents anybody comparing pure OpenJDK, IcedTea or other derived binaries with the “official” reference implementation binaries. This again is counter productive for the community that actually produces these GPLed binaries. Mark Reinhold used to publish binaries of the Jigsaw work in progress under free terms on dl.openjdk.java.net, which would be a much better fit. Finally the proposed TCK license contains (field of use) restrictions. These were unworkable for OpenJDK6 and so a special Community TCK License Agreement had to be created. It would be nice if such special case TCK license terms weren’t necessary and OpenJDK7 derivatives could have a TCK license without GPL-incompatible restrictions from the start.

If these legal nitpicks could be fixed, then these platform JSRs look pretty sweet. Without these legal terms fixed however we could end up with a somewhat schizophrenic split community. Where those who collaborate on the open, free, GPLed implementation that is being standardized aren’t actually allowed to use the finalized specification, reference implementation and compatibility testsuite to check their own work.

5 Comments

  1. David Fu says:

    I wonder if there will be a time when the “Java Standard” will be come unimportant, just like Linux is not Unix. To prevent technical fragmentation, just make it a requirement to be Mauve Compatible instead(I think this was the original intention of Mauve?)!

    But I think it will take many more Brave people to take the Brave step…

  2. […] Moving Java forward through the JCP? Very reasonable and balanced commentary from Mark Wielaard calls for the licence terms surrounding JDK7 and 8 to be reconsidered in the light of the need for open source communities to be able to freely work with the specifications. (tags: Java OpenJDK JCP Specifications Standards OpenSource FOSS IcedTea GPL) […]

  3. David, I think it already is quite unimportant. A build of IcedTea, which is based on OpenJDK, may pass the TCK but people still tend to be upset when it crashes Eclipse.

  4. David Fu says:

    Hi Andrew,

    I guess all that remains is the Trademark issue… so will the “Java” name become unimportant too?

  5. Matthias says:

    Hi Davik, hi Andrew,

    it is not that easy. When the patents of oracle on the VMs feature expire you can call the language dalvik, kava or whatever, but google did what you imply. So write a JavaVM, that does not violate the Oracle patents and your clear to call it a dalvikVM and everybody will know that it runs java, but is not from oracle. So there are two parts: the name and the technology. The first part was solved by google and maybe the second also, if they win the case and invalidate the oracle patent claims.

    I currently think that oracle and google should both be intelligent: Oracle should release the TCK for FOSS usage – at least for OpenJDK (with the field of use limitation I don’t see any change for a combination with the GPL) and google should base it’s work on OpenJDK and call it Java again …

    Just my two cents

    Matthias