InfoQ

News

OpenJDK 6 to be based off of OpenJDK 7

Posted by Ryan Slobojan on Sep 04, 2007 12:00 PM

Community
Java
Topics
Open Source
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.

1 comment

Reply

qwqwqwq by berkay NiQuiL Posted Jun 30, 2008 12:14 PM
  1. Back to top

    qwqwqwq

    Jun 30, 2008 12:14 PM by berkay NiQuiL

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.