With JDK7, OpenJDK and IcedTea all evolving in parallel it can get confusing about how these projects relate to each other. David Herron, which is OpenJDK Quality Lead, tries to set the record straight and explains why the JDK7 has taken so long.
David starts of describing the differences between OpenJDK 6 and JDK 6:
OpenJDK 6 began as a fork of OpenJDK 7, and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite.
The bottom line is that OpenJDK 6 works rather well, several Linux distros are using it as their JDK, it can be built to pass the JCK6b test suite, meaning OpenJDK 6 can be used to build a compliant JDK, and unfortunately it is this evolutionary sidetrack which we hope will be relatively short-lived. It serves a purpose, namely of having an fully open OpenJDK compliant with Java6
He then goes on explaining the relation about OpenJDK and IcedTea:
It seems some people really like typing "./configure" rather than setting up environment variables and running "make". The IcedTea project originally began due to incompleteness in the OpenJDK (gaps due to encumbrances) and the community requirement of a fully open source toolchain and code base. IcedTea has long been a set of patches applied to OpenJDK, along with a different build system that is "./configure" based as I just said.
In OpenJDK we've replaced the encumbered code such that there are no gaps any longer. As we've done so I believe the IcedTea project has shrunken the number of patches they use. One nice thing seems to be that the IcedTea configure script makes it easy to build OpenJDK in many different modes such as using the Zero Assembler port to support compiling on non-x86/sparc chipsets, etc.
A big piece IcedTea provides is a plugin/java-web-start infrastructure. We haven't been able to open source our plugin and of course for 6u10 we completely rewrote the plugin. It is hoped we will open source the new plugin into the OpenJDK project but to my knowledge that decision has not been made concrete set in stone.
David suggests that JDK7 and OpenJDK7 will have (nearly) identical code bases:
… the plan is that beginning with OpenJDK7/JDK7 that the code bases will be nearly identical. It is obviously expensive to maintain a fork, and if JDK7 were to diverge strongly from OpenJDK7 it would do two things: a) be very expensive, b) undermine our efforts at an open source ecosystem.
But "nearly identical" does mean it's likely there will be some differences.
Remember those gaps due to encumbrances? Some of those gaps were simply code we couldn't open source as of May 2007 but have since done so, other gaps are for code we still have to gain approval on (e.g. SNMP), but there is some code where there are open source replacements where we still use the old closed source code. This is primarily in font and graphics rasterization. The old closed source rasterisation code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, for any open source replacement to displace that code in productized JDK builds, it would have to be provably as fast and stable and good quality as the existing closed code.
The OpenJDK source release, JavaFX and an overall shortage of resources are according to David the reasons for JDK7 taking so long:
If we had followed normal release patterns JDK7 would be shipping about now. That is, Java6 shipped in December 2006 and our normal pattern is 18-24 months between major releases meaning the JDK7 launch would have been 2-5 months ago. What happened? Well, clearly there was a resource crunch on several angles.
For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people. But there was also certain announcements at JavaONE in May 2007 (a little thing named JavaFX) which also turned into a major rethink of Java (as some have said, this ain't yer Dad's Java) and also a major piece of work to accomplish.
In other words instead of producing JDK7 we did JDK6u10 and JavaFX.
Similar claims about how JavaFX has slowed down the evolution of the platform have also been made by Joe Winchester at a recent editorial for the Java Developers Journal where he compares the adoption of dynamic languages and technologies like JavaFX by Java, to the efforts of the Smalltalk team back in the 90’s, to make Java run on their VM (called the Universal VM). The author states that, as in the case of Smalltalk, it would be much better to focus on Java itself “rather than bloat and hack the JVM to become Jack of all trades”.
It is important to note that with the OpenJDK Governing Board’s life approaching to an end, there are those like Neal Gafter that are concerned about its new composition:
The OpenJDK governing board, having had its life extended by a year, is now scheduled to dissolve in four months, with two of its non-Sun positions remaining unfilled. The last published meeting minutes were from April 2008, at which it was agreed that the GB would strive for a draft Constitution by the end of 2008.
Who are the seven members of the governing board? Can we please see the minutes of meetings after April, and get a status report on the Constitution?
What do you think about Sun’s JDK and the future of Open Source Java?
