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.