Since you\u2019re reading this blog, chances are that you\u2019re writing software which will eventually run on a JVM. Most of you are using the Java language. Many of you are using a variety of other languages that target the JVM, such as Scala, Kotlin, Clojure, Groovy, (J)Ruby etc. Eventually you\u2019ll need to decide on which JDK\/JRE to deploy your software on in production. This is much easier said than done. There are quite a few different vendors out there, providing support and taking responsibility for the binaries they produce. They can have different support lengths for specific versions, and whereas you can sometimes find a vendor providing extended support for a version that has been officially end-of-lifed at Oracle, you may not find builds with the latest fixes in them publicly available. You\u2019ll need to get those directly from the vendor.<\/p>\n
After trying to figure out what\u2019s what, I thought I\u2019d simply write a blog post on the various JDKs available out there. This is especially important, since you might be consuming your JDK from a container provided by a third party, e.g. Docker Hub, and you may not know exactly what you\u2019re getting[1].<\/p>\n
Typically most companies will require that you keep your dependencies up-to-date. For example, if you\u2019ve written something with a dependency on Tomcat, you are pretty likely to keep your dependencies up-to-date. GitHub may even warn you if you\u2019re running with a version that has known security implications. However, not everyone is keeping their JDKs\/JVMs up-to-date. Which is funny, in a way, since everything you\u2019ll be running could be affected.<\/p>\n
Let\u2019s take the Oracle JDK as an example. JDK 7 was GA in July 2011. Publicly available updates and fixes ceased in April 2015. Oracle\u2019s Premier Support ended in July 2019, and even the Extended Support ends 2022.<\/p>\n
Let\u2019s say you\u2019re running on JDK 7. If you got your JDKs from Oracle, without a support contract chances are that the latest version of JDK 7 you got was built in 2015. You are now five (5!) years behind on critical security patches.<\/p>\n
In other words, if you\u2019re still running your software on JDK 7, you may want to at least begin upgrading to 8. JDK 7 is dying and support is being dropped left and right. If you aren\u2019t buying support and have someone provide you with (security) patches, you might want to accelerate the effort. Also, this particular upgrade (7->8) should be relatively painless \u2013 in most cases it will be a drop in replacement. Now, if you\u2019re not running a JDK 7 with the latest patches (sanity check \u2013 was the JDK at least built this year?), you may not only be missing out on bug fixes, but you may also be missing out on security patches<\/a>[2]!<\/p>\n The same arguments could be made for JDK 8 as well, on a slightly pushed out time-line. The good news is that there are still public (and free) updates coming from the OpenJDK 8 maintenance project. That said, there are plenty of advantages for upgrading to JDK 11+, better performance being one of them.<\/p>\n Now, when the new, faster, release schedule was announced, Oracle announced that every 3 years, there would be an LTS (Long Term Support) version of Java. The releases in between the LTS releases would only be supported until the next release came out. Most vendors have adopted the same support scheme, which means that, at the time of writing, you should not be running ANYTHING on JDK 9,10,12 and 13 (unless you\u2019re using Azul distributions, see [3]). They are not supported. Running them will only mean that you are lacking bug- and security fixes. To take a somewhat arbitrary example – if you stopped upgrading JDK 8 after 8u74, you are literally lacking thousands of fixes<\/a>.<\/p>\n At the time of writing this blog, the new CPU (Critical Patch Update) releases have just been published, and these are the releases you should be running in July 2020 (sooner rather than later):<\/p>\n If you\u2019re running anything else in production, without a support contract, it could be argued you\u2019re not doing things quite right.<\/p>\n OpenJDK, being open sourced, has builds provided by plenty of vendors. Here is a non-exhaustive<\/strong> list of some vendors shipping supported versions of OpenJDK (in alphabetical order, distribution(s) in parenthesis):<\/p>\n These providers usually ship distributions with pretty much the same bits from the OpenJDK repository, sometimes differing by what features are enabled, for example like a GC (Shenandoah \/ Red Hat), or by adding proprietary features like a new compiler (Falcon \/ Azul (Zing)). Some vendors have a free distribution (e.g. Oracle OpenJDK, Azul Zulu) and one that requires a commercial license (Oracle JDK, Azul Zing). Which vendor and distribution you should select depends on your demands \u2013 e.g. which vendor can provide reliable support to you (Oracle is one of the biggest contributors to OpenJDK), or which one provides the feature you need at a price point you can afford (e.g. JDK Flight Recorder on JDK 8 without the need for a commercial license, or support for a specific GC or compiler).<\/p>\n There are also upstream builds, not supported by anyone, built on Red Hat infrastructure and hosted by AdoptOpenJDK. For example, if you get a JDK 8 from Docker Hub (openjdk\/jdk8u252, openjdk\/jdk8), that is what you would get<\/a>.<\/p>\n As you probably know, JDK Flight Recorder, a technology close to my heart, has been backported to JDK 8. Since we\u2019re talking about where to get your JVMs and versions, I thought I\u2019d include a small table for which provider will be including JFR in what version of their JDK 8 builds.<\/p>\n Thanks to Mario Torre, JP Bempel and Gil Tene for feedback!<\/p>\n [1]: Mystery meat OpenJDK builds strike again: https:\/\/mail.openjdk.java.net\/pipermail\/jdk8u-dev\/2019-May\/009330.html<\/p>\n\n
What\u2019s what?<\/h2>\n
\n
Where to get JFR – Public Service Announcement<\/h2>\n
\n\n
\n Vendor<\/th>\n First JDK 8 Version with JFR<\/th>\n Release Date<\/th>\n Docker Image<\/th>\n<\/tr>\n \n Azul (Zulu)<\/a><\/td>\n u212* (u262+ recommended)<\/td>\n 2019-04-16<\/td>\n azul\/zulu-openjdk\/8<\/td>\n<\/tr>\n \n AdoptOpenJDK<\/a><\/td>\n u262<\/td>\n 2020-07-16<\/td>\n adoptopenjdk\/8u262<\/td>\n<\/tr>\n \n Red Hat<\/td>\n u262<\/td>\n 2020-07-15<\/td>\n In Fedora and RHEL<\/td>\n<\/tr>\n \n Amazon (Corretto)<\/a><\/td>\n u262<\/td>\n 2020-07-14<\/td>\n amazoncorretto:8u262<\/td>\n<\/tr>\n \n Bell-Soft (Liberica)<\/a><\/td>\n u262 (separate binary)<\/td>\n 2020-07-14<\/td>\n N\/A<\/td>\n<\/tr>\n \n Upstream builds [4]<\/td>\n u272<\/td>\n 2020-10-20<\/a><\/td>\n openjdk\/jdk8u272, openjdk\/jdk8<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Summary<\/h2>\n
\n