Musings on JDK development

OpenJDK 6 Genealogy

To address some of the questions that have come up recently in
and elsewhere, I've prepared a diagram of OpenJDK 6's genealogy:

alt="JDK Release Genealogy"
title="JDK Release Genealogy">

The original JDK 6 code base begat two lines of heirs: JDK 7 and the sequence of 6 update releases. The decision to open source the JDK code base came late in the life cycle of the development of JDK 6 so a build of JDK 7 was the first be published as open source. By the time JDK 7 was published as OpenJDK 7, the first post-GA update to JDK 6, 6u1, had already shipped. Work continued in both the OpenJDK 7 and 6 update trains. However, an open source implementation of the Java SE 6 specification was needed as well. After considering the alternatives, OpenJDK 7 build 20 was chosen as the basis of a backward branch to create OpenJDK 6 by removing changes inappropriate for a Java SE 6 implementation. Since then, all three trains, 6 update, OpenJDK 7, and OpenJDK 6, have continued evolving, with certain fixes being ported between the releases.

At some point in the future, the OpenJDK 7 code base will in turn presumably give rise to OpenJDK 7 update releases and OpenJDK 8.

Join the discussion

Comments ( 17 )
  • mbien Tuesday, November 4, 2008

    thank you for the dependency tree.

    Does this mean that there wont be a propretary JDK7 only a 100% open OpenJDK7 release?

    Since the jdk includes the jre, would we also get the browser plugin, webstart etc with OpenJDK7?



  • Joseph D. Darcy Tuesday, November 4, 2008


    I would expect there might remain some differences around the edges between the code used for OpenJDK 7 and the code used to build what Sun ships as our proprietary JDK 7.

    However, I would also expect that the OpenJDK 7 code from Sun will be able to build and implement the specification without any binary plugs. For OpenJDK 6, the only remaining binary plug is for SNMP support, which isn't a required part of the platform. We haven't gotten around to removing a few plugs from OpenJDK 7 that have been removed from OpenJDK 6, but it is just a small matter of programming to do so. Even today in JDK 7, the vast majority of the code is semantically the same between an openjdk=true build and a proprietary build.

  • anjan bacchu Tuesday, November 4, 2008

    hi there,

    thanks for the info. The diagram itself can be confusing :-)



  • Volker H. Simonis Wednesday, November 5, 2008

    Hi Joseph,

    I think the arrow from "OpenJDK7" to "7u1" is quite confusing. In my understanding, you only have update realeases for released versions of the JDK and as you commented, officialy released JDK versions are not 100% equal to OpenJDK versions because they contain additional, closed sources.

    So if I understand things right, at a certain point in time, there will be a branch from "OpenJDK7" to "JDK7" which will then be released eventually. After this GA release of JDK7, JDK7 will fall back into "maintainance mode", resulting in a number of "update" releases while the further development will take place in the newly created "OpenJDK8" branch. Is this right so far?

    Another simplification in your dependency graph is the fact that you look at the JDK as a single entity and ignore the fact that certain parts like for example the HotSpot have been integrated back from the "OpenJDK7" train into the JDK6 train with certain update releases. This may also be true for OpenJDK6, although I don't know this for sure. A complete picture of these dependencies would be nice (I was already thinking about doing something similar myself) although that diagram would be of course even more complex and potentially confusing.



  • Joseph D. Darcy Wednesday, November 5, 2008

    Hello Volker.

    The dashed arrows from OpenJDK 7 to 7u1 and OpenJDK 8 were meant to convey some uncertainty about the future. However, after OpenJDK 7/JDK 7 ships, I would expect some form of maintenance or update releases to occur on that code base in parallel with development of the next platform release.

    The full situation of the JDK code is rather more complicated than this diagram tried to convey! A to-be-written blog entry of mine discusses the differences between an openjdk=true build and a "closed" one. However, the code in both kinds of build variants is mostly the same; official closed builds do a license swap and use the closed repositories which aren't published externally. This similarity is why I put a line from JDK 7 b10 to OpenJDK 7 build 11; it was the majority of the JDK 7 code base starting a new life as an open source project.

    I would expect the comparatively large differences between OpenJDK 6 and the 6 update release to be much larger than the differences between any future OpenJDK 7 and 7 update releases. Since open sourcing the JDK occurred after JDK 6 shipped and OpenJDK 6 came about only some time later, OpenJDK 6 is a base case and I wouldn't expect it to be representative of future releases.

  • Volker H. Simonis Wednesday, November 5, 2008

    Hi Joseph,

    thank you for your explanations. My point was if the changes/fixes to the JDK7 update releases will be done "in the open" like the current changes in OpenJDK7 happen in the open (variant B below), or will their be a special, closed branch for the official "JDK7" release train (variant A below).

    Variant A: If there will be first a branch from the OpenJDK7 (plus license swap and merge with the closed repositories) and then all further work on the official JDK7 release train will happen on that branch, that would be bad, because that branch will not be "open".

    Variant B: If however the license swap and merge with the closed sources will be done in the build process, after pulling most of the code from the an open JDK7 branch, that would be nice, because in this case, we could follow most of the work (patches, bug fixes,..) for the JDK7 update releases in the open. This would however also expose certain fixes (e.g. security fixes) immediately to the community (because they will most likely happen in code which is in the 99% of the open part rather than the 1% of the closed part). And this will happen before they are released in an official update which I personally don't see as a big problem and which is good for the community but which is in contradiction to Suns current policy.

    If my understanding is right, the closed repository contains just "supplementary" code with regards to the OpenJDK repository and there's no code duplication between them. It would be nice if this would also be the case for a future "JDK7" repository.

    Please correct me if I'm not right with any of my assumtions!



  • Joseph D. Darcy Wednesday, November 5, 2008


    With the usual caveats about an uncertain future, I would expect your "B" variant to be closer to how any JDK 7 updates will be managed.

    However, I think security fixes will continue to be developed internally and then released publicly the same time binaries with the fix were made available.

  • Mark Wielaard Thursday, November 6, 2008

    Why would you need any "license swap" in the future? It would be good to have the pristine source code identical between shipped releases from everybody creating a product from the upstream OpenJDK code base.

    If Sun feels they need a special license for shipping their own binary releases that are derived from OpenJDK that is different from all other binary releases done by others in the community that implies there is a flaw in the system IMHO.

  • mbien Friday, November 7, 2008

    IMO the only reason which would justify a proprietary SUN JDK7 is that some of the binary plugs would still have better quality/stability/performance as their open implementations (because of patents evil third party licenses or similar things).

    keeping two similar implementations of software with the size of the JDK and different licenses in sync (rfes, bug fixes etc) is an enormous effort...

  • Tyler K Saturday, December 6, 2008

    Hi Joseph,

    I had previously written a quick synopsis of OpenJDK's background in the openSUSE wiki (URL:http://en.opensuse.org/OpenJDK), but I see that my description is not entirely accurate. I would like to update that information and include the nice little diagram you created -- so, to cut to the chase, I'm seeking your permission for re-use of the image in the openSUSE wiki.

    Thanks, Tyler

  • Joe Darcy Tuesday, December 9, 2008

    Hello Tyler.

    I'll keep the url to the image file stable if you just want to link to it; otherwise you can use the image in the openSUSE wiki (but I wouldn't mind some attribution, if possible :-).


  • Tyler K Thursday, December 11, 2008

    Thanks Joe. I think I will use a copy of the image, but I will most definitely provide attribution to you and also include a link to your blog ... might not be able to get to this until next week sometime, but I'll post back when I'm done so you can have a peak. Cheers

  • Eric Bresie Wednesday, January 7, 2009

    This may seem to be a little late, but I found this very informative.

    I think it is safe to say there are diff's or patches between each of these items except for cases where branches occurred with new branch names/tags/aliases.

    You indicated changes to the OpenJDK7 were backported to OpenJDK6 with non-JDK6 changes being omitted.

    So if all this is true, then what ever happen to the patches that occurred along the 6u1...6u2...6u10 (now 6u11/12) lines. Were they ever included in the OpenJDK 7 (b11...b22) and to OpenJDK 6 (b01...b12) branches?

    Not sure if it's appropriate to mix the two/three, but any chance of some indication of where the JavaME / phoneME and JavaEE / Glassfish source fits in to this mix? I know JavaME has roots somewhere in the 1.4.x source time frame which may be way too far back to include. I know Glassfish is built on top of and against a given version of SDK.

    Once again thanks for the post.


  • Joe Darcy Wednesday, January 7, 2009


    Yes, generally there are some differences between the release trains. However, many files are likely to have identical contents: some parts of the platform are now stable and evolve slowly, other parts of the platform are kept in sync across release trains.

    OpenJDK 6 is a "backward branch" from OpenJDK 7:


    That is, we started with the OpenJDK 7 sources and removed changes inappropriate for a Java SE 6 implementation; this eventually resulted in a distinct Java SE 6 implementation only indirectly related to the source for the 6 update release.

    As announced previously (http://blogs.sun.com/darcy/entry/openjdk_6_and_6u10_features), the 6u10 features will in time be ported to JDK 7; afterward, those features may or may not end up in OpenJDK 6.

    As far of the ME source code, I don't know its pedigree in detail, but the last common point between it and Java SE sources is no later than some JDK 1.4 release. I'm not that familiar with the evolution of GlassFish or EE.

  • Satish Chhatpar Monday, August 6, 2018
    In our environment there is a need to upgrade openJDK from java-1.6.0-openjdk.x86_64 to openJDK 1.7.

    Operating System - Red Hat Enterprise Linux Server release 7.5 (Maipo)

    Before doing these please share differences between openJDK1.6 and openJDK1.7
  • Satish Chhatpar Monday, August 6, 2018
    What is difference between java-1.6.0-openjdk.x86_64 and openJDK 1.7 ?
  • Joe Darcy Thursday, August 9, 2018

    This blog is not a support channel.

    Please direct your inquiry elsewhere.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.