How does the maintenance of OpenJDK work in practice?

Question

Specifically, I would like to understand the difference between Oracle's JDK and OpenJDK in terms of bug fixes and other patches.

Which branch gets fixes first and is Oracle in a habit of making patches that never make it to OpenJDK?

Answer 1

This is explained in much details at OpenJDK page: JDK 7 Update Project Proposal Q & A

Will this Project serve as the basis for Oracle JDK 7 Update releases?

Yes.

To quote from Joe Darcy's FOSDEM blog post on OpenJDK 6:

In particular, there will not be the same dichotomy between the OpenJDK 7 code base and the 7 update code base as there is between OpenJDK 6 and the 6 update train...

Per my reading, above essentially means that patches and updates will typically go first to Open JDK and then, with as small delay as possible, delivered in Oracle JDK.

For security patches, the picture seems to be opposite, ie I'd rather expect them to go first to Oracle releases and then (again, with as small delay as possible) to OpenJDK:

Will the 7 Update Project receive security fixes from Oracle?

Yes.

As with OpenJDK 6, security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to affected JDK release trains. In addition, they will not go through the public code review and putback approval process, and their corresponding issues in the Project's issue tracker will not be publicly visible.

When will this Project receive security fixes from Oracle?

The schedule for Oracle Java SE Critical Patch Updates is publicly available.

Security fixes for this Project's source code will be made available in the JDK 7 Update Project around the same time as they're released in products from Oracle...

---

To better understand the reasons why there seem to be so much effort put into keeping Oracle and Open JDKs in sync, it makes sense to take a look at the Oracle decision on preceding project: Moving to OpenJDK as the official Java SE 7 Reference Implementation:

...Oracle and the other members of the Java SE 7 Expert Group have been putting the finishing touches to the Java SE 7 specification (JSR 336). In its role as the specification lead, Oracle is responsible for delivering the Java SE 7 Reference Implementation... we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license.

The role of the Reference Implementation (RI) is to be used as the gold standard for all Java implementations. In order to have an implementation certified as Java SE compatible, an implementor must pass a large number of compatibility tests - the Technology Compatibility Kit (TCK). Furthermore, implementations may be compared to the RI as an additional check of compatibility. Basically, if your implementation has been certified to have the same behavior as the RI then it is Java compatible. For more information on this topic, consult the JCP FAQ.

Historically, Sun always used the Sun JDK as the RI and made it available under the Binary Code License (BCL). This was very convenient for Sun since it meant that its product implementation was compatible by definition. However, it was also confusing since the Sun JDK contained quite a few features that were not part of the standard, such as the Java Plugin. Also, continuing this practice would make things difficult for open source implementors as they would not be able to study and evaluate the official RI source code. (The source code for the Oracle JDK is slightly different from OpenJDK - something we will be addressing moving forward).

With that in mind, Oracle will:

• Create RI binaries based only on the OpenJDK code base.
• Make RI binaries available under the BCL (the normal Java license) for commercial implementors and GPLv2 (with the Classpath exception) for open-source implementors.
• Continue to provide the TCK to commercial licensees, but also update the OCTLA license so that it covers Java SE 7. The latter allows open source implementators gratis access to the TCK to verify their implementations...

Above decision means a lot of effort to put into Open JDK code, to release officially verified, tested, licensed and compliant code. If you add that it has to be released following the agreed public schedule, it becomes obvious that such an effort will be about the same as previously was put into "traditional" Sun/Oracle Java releases.

This makes it only reasonable to keep Open and Oracle JDK code bases as close as possible: otherwise, duplication of development and fixes to make both projects compliant with TCK could become prohibitively daunting.

It looks like decision to use Open JDK as a Reference Implementation made it in the best interest of Oracle to keep their JDK as close as possible in sync with Open JDK - up to release of JDK 7.

To understand what could motivate Oracle to keep mentioned sync further, with JDK 7 update releases, one would better take a look at the Open JDK 8 project, which purpose is described pretty much similar to that of Open JDK 7:

The goal of this Project is to produce an open-source reference implementation of the Java SE 8 Platform, to be defined by JSR 337 in the Java Community Process.

For the same reasoning as was explained above regarding reference implementation of JDK 7, it is, again, in the best interest of Oracle to keep the updates of both JDKs as much in sync as possible.

The more differences would be between these JDKs now, the harder would it be for Oracle to release Java SE 8, due to duplication of efforts necessary to bring their own release into compliance with TCK. The opposite is also true, ie the closer both projects are going to be now, the less effort will be required to release both Java 8 implementations.

---

Did it ever happened to you to support in parallel two slightly different versions of the same software, targeted at different clients? If yes, you likely remember the desire to keep them both as close as possible, and the inconveniences you experienced when these were out of sync. With Open and Oracle JDKs, it is pretty much like that, only on a larger scale.

Answer 2

Almost all bug fixes go directly through the OpenJDK project and then into downstream JVM vendors (Oracle, Azul, RedHat etc).

An exception is that some security patches are fixed in downstream versions (in particular Oracle) before quietly being ported it back into OpenJDK. This allows the vendors to upgrade most of the world with the security fix before publicising the vulnerability in the open source project.

Some vendors also choose not to push their changes back into OpenJDK. For example both Google and Twitter have modified OpenJDK versions that they use internally with bug fixes and features that have not gone back into the main OpenJDK project.

HTH