Moving to OpenJDK as the official Java SE 7 Reference Implementation

Update 7/22/2011: The JavaSE 7 Reference Implementation is now available for download from

We are now less than two months away from the JDK 7 release date. In parallel with the development project, 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. In line with our strategy towards a more open Java ecosystem, 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.

We believe that these changes will lead to improved clarity in the Java community, as well as make things easier for both commercial and open source Java SE implementors.

Update: I have been asked to make a couple of clarifications. First, there is no change to our policy vs Apache Harmony. OCTLA is a program that allows free access to the TCK for OpenJDK-derived implementations licensed under GPL and is only intended for that purpose. Second, the Oracle implementation (what you find on or will remain under the BCL license only. Finally, to be completely clear, the OpenJDK source code remains under GPL.


"...but also update the OCTLA28 license so that it covers Java SE 7. The latter allows open source implementators gratis access to the TCK to verify their implementations." Wow. So does that mean that Apache will _finally_ be able to certify Harmony? (Assuming it is, in fact, compatible!) Or have I misunderstood something? Thanks

Posted by guest on June 09, 2011 at 12:48 AM PDT #

Apache Harmony is witness to the fact that the OCTLA does not allow "open source implementators gratis access to the TCK to verify their implementations." That license is "Subject to and conditioned upon its Licensee Implementation being substantially derived from OpenJDK Code and, if such Implementation has or is to be distributed to a third party, its being distributed under the GPL License"

Posted by Neal Gafter on June 09, 2011 at 02:12 AM PDT #

Is Android an "OpenJDK-derived" implementation for OCTLA (lawsuit vs. Harmony-based)?

Posted by guest on June 09, 2011 at 04:16 AM PDT #

Is the TCK the RI of a java certification test suite? Shouldn't certification be done by an independent third party? Maybe someone without an implementation? Is there a JSR spec documenting the TCK requirements and its expected output so other TCK implementations can be made? If not, the why not? If yes then where? Why not open source the TCK in the spirit of transparency?

Posted by Eric B on June 09, 2011 at 04:51 AM PDT #

Oracle is afraid of Apache Harmony.

Posted by guest on June 09, 2011 at 05:46 AM PDT #

Neal, note that is only a restriction on the current OCTLA. Henrik explicitly said they would update it to cover open source implementors for JDK7. So I fully expect this to also be applicable to Harmony once it updates to JDK7.

Posted by guest on June 09, 2011 at 06:03 AM PDT #

Typo: visavi should be vis-à-vis

Posted by guest on June 09, 2011 at 07:19 AM PDT #

Why do people still use the INSANELY stupid and OUTDATED GPL cancer? The GPL is nothing but a stupid religion for dorks who are stuck in 1970.

Posted by guest on June 09, 2011 at 08:44 AM PDT #

Thanks for the comments. I have added a clarification on Harmony to the entry; there is no policy change on that subject. On Android; I don't believe it is OpenJDK-based nor GPL; if it were then Google could apply for a TCK through the OCTLA. Finally, I have fixed the typo ("visavi" is the Swedish spelling). -- Henrik

Posted by Henrik Stahl on June 10, 2011 at 12:42 AM PDT #

This means that the Java SE 7 RI won't run on Windows? Or do you plan to deliver a Windows port of OpenJDK?

Posted by Fernando Lozano on June 10, 2011 at 01:10 AM PDT #

We plan to produce Linux and Windows RI binaries from the OpenJDK code base. Technically, only one is needed but traditionally Sun provided more than one to facilitiate for implementors. Note that the RI has a very specific purpose (eg, to serve as the RI) and is generally not updated except when/if the specification is revised.

Posted by Henrik Stahl on June 11, 2011 at 05:06 AM PDT #

So other than purchasing/licensing the TCK, there is no way for a "non-OpenJDK" derived version of Java to be developed. Doesn't seem like very open and transparent environment. What about usage of the OpenJDK on devices besides desktop? Is there still the same field of use restrictions in place? The problems seems to be licensing of the TCK, certification of a "implementation" (non-openJDK based), and the field of use restrictions. How are all these planned to be addressed? But then again, I think my previous feelings are still relevant ( and that Google should just license the TCK for Apache Harmony and be done with the whole thing.

Posted by guest on June 11, 2011 at 11:20 AM PDT #

"Note that the RI has a very specific purpose (eg, to serve as the RI) and is generally not updated except when/if the specification is revised." Could you clarify this? Does that mean that the minor "updates" that occur from time to time will not be applied to te RI until the next major version? If so, is there a record for third parties (such as the Linux distros) to do the patching themselves?

Posted by Cay Horstmann on June 11, 2011 at 06:48 PM PDT #

A positive and welcome step - Cheers, Martijn

Posted by Martijn Verburg on June 12, 2011 at 01:29 AM PDT #

Ok, it seems like here is a lot of confusion on this topic. To start with, OpenJDK is a GPL-licensed open source project. All normal GPL rights and restrictions apply. If you take the OpenJDK source code and build a binary from it, you can do anything with it that GPL allows. OCTLA is a license that allows you to get a Java SE TCK license for free (gratis) for any Java SE implementation that is derived from OpenJDK and licensed under GPL. The second option is to get a Java SE binary (JDK or JRE) from Oracle, normally under a BCL license which is free-as-in-beer but not open source and subject to certain restrictions - see the BCL for details. We build our JDK by taking the open source OpenJDK code base and replace/add certain proprietary (non-OSS) components to it. This mainly has historic reasons and we have a goal to minimize the differences between our "propietary" code base and OpenJDK. So far, so good. Now, for any JCP specification the spec lead must provide a TCK and a RI. These are really only intended to be used by specification implementors. In the case of Java SE, this means Oracle, IBM, HP, SAP, Red Hat and other licensees. Some of them want a closed implementation and get a commercial TCK licens from Oracle. Some want an open implementation and base it on OpenJDK and get a TCK license under OCTLA instead. Both of these groups also need a RI to compare their implementation with. As explained in the blog post, this used to be the Sun JDK (not OpenJDK) and under BCL only (not GPL). In order to facilitate for open source implementors (eg OpenJDK-derived GPL-licensed implementations such as IcedTea) we will now build the RI based on OpenJDK (not Oracle JDK) and license it under GPL as well as BCL. The RI is built once when the specification is finalized and not touched again (no updates, no patches, no security fixes) except when/if there is a specification revision. Oracle offers no support for it except for specification implementors as mandated by the JCP. If you are a normal user or developer, you can use the RI - there is nothing in the license that prohibits that - but it is more likely that you will use the Oracle JDK, a JDK from one of the Java SE licensees or an OpenJDK-based implementation built by one of the Linux distributions, or by yourself. If you are still confused, please read the JCP FAQ very carefully before posting more questions on this topic here. Cheers -- Henrik

Posted by Henrik Stahl on June 12, 2011 at 04:15 AM PDT #

Here's my prediction: - Oracle has already announced plans to merge Sun's VM and JRockit (sensible on the surface given they own both technologies). - OpenJDK may be adequate as a RI, but in my experience is very poor and unstable compared to Sun's. I wouldn't use it in production. Period. - Oracle refuses to ever make Harmony an official, proven Java VM because; - Oracle plans to license then charge extortionate amounts for the only production-worthy Java VM

Posted by guest on June 12, 2011 at 09:29 PM PDT #

So what happens if the community wants to update the OpenJDK atfer the initial RI release?
Why does Oracle say "The RI is built once when the specification is finalized and not touched again (no updates, no patches, no security fixes)"? Oracle doesn't own OpenJDK, why are you setting rules for it?

Posted by alex on June 19, 2011 at 02:01 AM PDT #

Is it correct that there will be no updated (OpenJDK based) _RI release_ except when/if there is a specification revision, but developers will continue to work on the OpenJDK source code base, which can lead to OpenJDK _non-RI_ releases/ Oracle JDK releases?

Or does Orcale develop fixes in a closed-source environment and eventually back-port them to OpenJDK?

Posted by Florian Brunner on June 22, 2011 at 04:26 AM PDT #

I suspect the RI submitted would be like a "Released Version" of any product. A baseline release that complies to the TCK upon submission to the JCP.

Any changes by the community would occur in the open in the Open JDK project.

You could (1) use the RI version of the JDK, (2) use a version with changes from the open JDK, (3) use a commercially licensed version (with proprietary enhancements and possible patch changes) from Oracle, or (4) use a commercially licensed non-Oracle version with any potentially enhancements of the non-Oracle company, or (5) use an implementation which has been tested with a licensed TCK.

If any significant changes occur that would require changes to the spec, then an update to the spec, RI, and TCK may be required, which would likely require an update to an existing spec or a new JCR all together.

Although I am still confused as to how a TCK targeted for the RI / OpenJDK can be used with a non-OpenJDK derrived target implementation. If the TCK has test cases intended to test the behavior relative to the spec, then this would be good to insure meets spec requirements. If however, the TCK is testing something specific to the implementation, then non openJDK derived implementation could by nature fail due to differences in implementation. Isn't this the same sort of fragmentation problems that has dwelled in the ME community (i.e. each ME implementation had its own problems) for so long?

Why not re-engineer the OpenJDK to be compatible on mobile devices with a "mobile profile" (taking a page from the Java EE realm). If something like this is not done, then fewer and fewer mobile devices will be supported, risking a lost opportunity on the mobile space.


I do not work for Oracle, Google, IBM, Apache, or anyone with a significant stake in this...I only speak for myself as a supporter of Java.

Posted by EricB on June 24, 2011 at 02:53 AM PDT #

Kudos for the announcement! I see this as a step in the right direction. Now, could you please elaborate when you say: 'We build our JDK by taking the open source OpenJDK code base and replace/add certain proprietary (non-OSS) components to it.'? Thank you in advance.

Posted by guest on July 31, 2011 at 06:47 PM PDT #

Henrik, does any of this change how java software applications work with Java SE 7 ? Is there a difference whether these applications are proprietary or open source (gpl or other)? Is there a difference if these apps run on desktops, servers, VMs or mobile devices (assuming SE 7 is available on these)?

Posted by guest on August 31, 2011 at 06:53 AM PDT #

This change really only impacts Java SE implementors, not end users. And in particular, it is intended to facilitate for GPL-licensed open source Java implementations.

Posted by Henrik Stahl on August 31, 2011 at 07:03 AM PDT #

Given the circumstances I understand that why Google increasingly tries to create alternative languages/runtimes our there (Golang, Dart and why not JavaScript). IMO Oracle is steadily moving Java to the "legacy" technologies corner.

Posted by guest on December 11, 2011 at 10:32 PM PST #

IMHO - since Oracle took over Java it has made it more and more less attractive as a programming language. Me thinks Microsoft is in back room deals with old Larry to destroy it. I'm seeing nothing but bad things coming down the pipe for Java. .Net isn't any better of an alternative. maybe it's time everyone just went back to C/C++ where there are FAR FEWER restrictions and litigation BS. It's HIGH time software patents were outlawed and negated. Oracles actions with Java "derivatives" is a prime example of this.

Posted by guest on December 18, 2011 at 04:11 AM PST #

Post a Comment:
Comments are closed for this entry.

Henrik Stahl is VP of Product Management in the Java Platform Group at Oracle, and is responsible for product strategy for Java ME and SE.


« March 2017