OpenJDK 6 to be based off of OpenJDK 7

Posted by Ryan Slobojan on Sep 04, 2007

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Open Source ,

Java

Tags

Java SE ,

Open source Java

Sun recently announced a plan for releasing a Java 6 version of OpenJDK, which will involve back-porting the OpenJDK 7 codebase to create a Java 6 compliant implementation. InfoQ spoke with Joseph Darcy of Sun to learn more about this decision.

When asked why Sun had decided to open source JDK 6 at this time, Darcy commented that this allows OpenJDK 6 to take advantage of the changes which have occurred to OpenJDK 7 to support both the Mercurial source code repository and the binary plug architecture. It also allows Sun to reuse the code audit and encumberance clearing work which was done on OpenJDK 7 - there was a significant effort involved there, and there was a desire to not complete the full process for a second codebase. Darcy was also asked what the difference was between OpenJDK 6 and the existing JDK 6 project, which also publishes it's source code - he indicated that the existing JDK 6 code is published under the Java Research License, whereas OpenJDK 6 will be licensed under version 2 of the GNU General Public License (GPL).

InfoQ next asked Darcy about the the impact that creating OpenJDK 6 would have on the development of OpenJDK 7, and he said:

The overall open sourcing effort of JDK 7 certainly has pushed out the JDK 7 schedule and we're making progress on determining the set of features. However, given the existing open source JDK 7, producing an open source Java SE 6 from that base should be a comparatively small effort so I don't anticipate any significant additional impact on JDK 7. Meeting our pledge of open sourcing a Java SE 6 will allow more attention to go to JDK 7 going forward :-)

Darcy was also asked what risks basing OpenJDK 6 off of OpenJDK 7 might have, and he said that any large restructurings to the existing API which were done for Java 7 may need to be found and reverted. However, his expectation was that most of the engineering work would be removing new classes and methods and reverting changed specifications which have relatively low risk. Darcy also mentioned that the Java 6 updates will remain off of the existing JDK 6 codebase for at least the next few releases, and that it was currently unknown whether Sun would switch to issuing updates off of the OpenJDK 6 codebase in the future.

Darcy also explained to InfoQ the other options that were available for open sourcing JDK 6:

One alternative was redoing all the code auditing and clearing of encumbrances on the 6 update workspaces. No one wanted to do that again! Another alternative was developing a technological wrapper around a JDK 7 build to have it only expose Java SE 6 interfaces based on the technology described in:

Emulating the Java ME Platform on Java SE by Kenneth Russell and Tony Wyant

Basically, user classes would be rewritten as they were loaded into the JVM so that they would only see a Java SE 6 view of the world; this technique can handle reflective access too. While this was technically interesting, various enhancements would have been needed to be developed and there were expected complications (non-Java interfaces, etc.), so this technique would certainly have had a longer time-to-market than the straightforward backward branch approach we chose.

Finally, InfoQ asked Darcy what he expected to happen in the future with OpenJDK 6:

In the near term, my focus will be on creating the public Mercurial repositories for OpenJDK 6. How the code base will develop after that point remains to be seen, partially because the external community will help determine the outcome. The JDK is used in an extremely diverse set of conditions, from big corporate banks to individual developers. The release model of how we fix bugs and incorporate features has to be a compromise across this spectrum of users. Creating OpenJDK 6 allows the Java SE 6 release model to be reassessed. Perhaps the existing update release can be transitioned to be based on the open code; on the other hand, perhaps having distinct update and he open code bases would better meet the needs across the spectrum. Once the OpenJDK 6 is published and in use, we'll have more information to guide future release model directions.

Darcy also hinted that OpenJDK 6 might reach a major milestone in time for JavaOne 2008.

• Older >