There was an interesting discussion on the Java Champions alias recently under the title, “Fear of Java”. The initial post was related to a University faculty that was evaluating which version of Java to use. Given the issue that it brought up, I thought it was worth discussing in a blog post.
I’ll quote the comment that started the discussion, without attribution,
“Oracle JDK / Oracle OpenJDK builds and OpenJDK builds from other providers will be built from the same source for the first six months of updates and should be interchangeable for that period. After six months Oracle JDK / Oracle OpenJDK builds will be built from Oracle’s own fork. Other OpenJDK providers will continue to create binaries from the OpenJDK updates project. Oracle JDK / Oracle OpenJDK and OpenJDK build from the other providers may, therefore, differ in small ways. Binaries from various parties may, of course, vary over time.”
The crux of the issue is the idea that over time, we will see a divergence of the Java platform as different distributors of OpenJDK binaries provide slightly different implementations from the Oracle JDK.
There are a number of reasons why this will not be the case and, in effect, nothing is changing. We can look at this from two perspectives: security patches and bug fixes/all other changes.
Some time ago, Oracle set up a group within the OpenJDK called the Vulnerability Group. This is a closed group, which, due to the nature of the work it undertakes, does not make any of its discussions public. The membership of the group in terms of companies and groups involved is not publicised, but the membership is listed publicly on the OpenJDK census page. Suffice to say that all the people involved represent those you would expect to have an interest in the area of JDK security.
The role of this group is to “…receive reports of vulnerabilities in OpenJDK code bases, review them, collaborate on fixing them, and coordinate the release of such fixes.” The critical word in that mission statement is collaborate. Members of this group all see details of the security issues and work together to develop patches. The result is that all primary distributions of OpenJDK binaries will have access to the same codebase for security patches. This eliminates the issue of divergence early on for these changes.
Updates to OpenJDK extend beyond security patches and include bug fixes and other minor improvements. Under the new release cadence, Oracle upstream all changes they make to the current OpenJDK repository only. The changes for the most recent update (in April) were upstreamed to the OpenJDK 12 repo. For non-Oracle binary distributions to include these changes, they must be backported to the source code of the older, supported versions.
Who does this backporting work depends on who provides the binary distribution.
Andrew Haley of Red Hat recently took over as the lead maintainer of both the OpenJDK 8 and 11 update projects. As Andrew pointed out in a recent blog, this does not mean that Red Hat has “taken over” the OpenJDK update projects (as you might have thought from an earlier Red Hat press release). Red Hat is a massive contributor to the OpenJDK projects, both for older releases (Andrew is also the project lead of the OpenJDK 7 update project) and new releases (there were two JEPs from Red Hat in JDK 11).
The April JDK update was different from those in the past, as it was the first time Oracle did not release a public update for a long-term supported version. The only free public update from Oracle was for JDK 12.
Engineers at Red Hat, in conjunction with others from the likes of Amazon and IBM backported the changes and immediately upstreamed the changes to the OpenJDK 8 and 11 update repos. Azul’s engineers did the same, independently.
An obvious question would be why did Azul do this? Surely, this is causing precisely the problem that the original post described.
Azul has two distributions of OpenJDK (similar in many ways to Oracle). Our Zulu Enterprise edition is a fully supported and TCK verified distribution of the OpenJDK (we support JDK 7, 8 and 11 with extended availability of updates). As part of the contract for our customers, we define service-level agreements (SLAs) for how quickly updates will be made available after Oracle release theirs. The highest level of SLA is 48 hours. To guarantee this, we cannot rely on the goodwill of other organisation’s engineers, so we do the work ourselves.
Our other distribution is the free Zulu Community edition, which is a straight build of whatever is in the current OpenJDK repo. This will contain updates only once the code has been upstreamed and therefore does not come with any SLA.
With the exception of Zulu Enterprise and the Oracle JDK, then, all OpenJDK binary distributions start from the same OpenJDK repo code. There is no divergence occurring in this case. The users of Zulu Enterprise and the Oracle JDK will be commercial customers, who require access to updates within a given time defined by the SLA.
This is the same process that has been working without issue since OpenJDK 6 stopped getting public updates. Andrew Haley took over the leadership of that project and updates have been backported and upstreamed ever since. More recently, Andrew resigned the leadership of the project and Andrew Brygin of Azul took over. We continue to upstream changes to OpenJDK 6.
It is, however, worth adding a few words of caution when selecting an OpenJDK binary distribution to use.
Firstly, there is the issue, raised recently by Azul’s own Gil Tene, of mystery meat JDK builds. Some of the Linux distros are using version strings that do not accurately reflect what is included in a given build. The second thing to bear in mind is that, although the starting point for OpenJDK binaries is the code in the OpenJDK repo, there is no requirement to use that without modification. Some OpenJDK binary distributors may well backport other enhancements not included in an update from newer versions. Users should check carefully to ensure that they are getting what they want from the binary distribution they choose.
With Zulu Enterprise and Community editions, we’ve covered everybody’s needs. Why not give it a try?
One last thing, more cowbell!
