The future of Java and OpenJDK updates without Oracle support
Oracle recently announced that it would no longer supply free (as in beer) binary downloads for JDK releases after a six-month period, and neither would Oracle engineers write patches for OpenJDK bugs after that period. This has caused a great deal of concern among some Java users.
From my point of view, this is little more than business as usual. Several years ago, the OpenJDK 6 updates (jdk6u) project was relinquished by Oracle and I assumed leadership, and then the same happened with OpenJDK 7. Subsequently, Andrew Brygin of Azul took over the leadership of OpenJDK 6. The OpenJDK Vulnerability Group, with members from many organizations, collaborates on critical security issues. With the help of the wider OpenJDK community and my team at Red Hat, we have continued to provide updates for critical bugs and security vulnerabilities at regular intervals. I can see no reason why this process should not work in the same way for OpenJDK 8 and the next long-term support release, OpenJDK 11.
I’m happy to assume leadership of the JDK 8 and 11 update projects if I have the support of the community.
At Red Hat, we intend to provide support for OpenJDK 8 to our customers until 2023, and our policy of always “upstream first” implies that OpenJDK 8 will continue to be updated for critical bugs and security fixes until then. Something similar will happen for JDK 11.
In addition to the people and organizations currently helping with OpenJDK updates, I have received offers of help from organizations not currently involved, in particular from Amazon Web Services. This bodes well, but it may take time to get everyone up to speed working as part of the community.
There is also the question of back-porting important features from later OpenJDK releases to, for example, JDK 8. While new features, particularly performance-related ones, are undoubtedly nice to have, our first priority must be to not break anything: we must remember that we are stewards of a very precious piece of software. Only if we are sure that we’re not taking unnecessary risks should we do major back-ports. We also have to consider the maintenance burden. So, each proposal will have to be taken on its individual merits, and I don’t think we can have a one-size-fits-all policy for such things.
One question which frequently arises is that of how people will get free downloads of compiled OpenJDK binaries, as opposed to the source code downloads that are provided by OpenJDK. I believe that the OpenJDK updates project itself should commit to providing binaries when releases are made. (Having said that, if you’re using some kind of Linux distribution, I would strongly recommend that you use the OpenJDK packages that are provided by the system and its package manager: you should get better integration and ease of updating that way. Some people might be worried that their chosen distribution will not build, test, and package OpenJDK correctly, but if you don’t trust your distribution to build packages, you shouldn’t be using it at all.)
So, when we talk about OpenJDK binaries we’re mainly talking about Windows and Macintosh downloads. It will be up to the JDK updates projects to decide how and where to build the binaries. Having said that, my team at Red Hat is happy to commit to providing regularly updated, tested (and, in particular, TCK’d) Windows and Linux downloads, but we probably will need help building and testing on Macintosh. I’m sure we can get this done and we can continue to deserve the trust of Java users.
Keeping Java updated in the absence of support from Oracle engineers will be a challenge to the Java community, but I believe it is one we should enthusiastically embrace. It is a golden opportunity for us, the community, to show what we can do. A truly open and transparent OpenJDK updates project will encourage wider participation and benefit all Java users.