In 2018 Oracle quite unexpectedly decided to charge for Oracle JDK production use. This decision to start charging for its JDK led to considerable uncertainty and confusion in the Java community all around the world.
Over three years passed and in September 2021 this, quite problematic, decision from the industry giant was reversed. The Oracle JDK is available free of charge for production use again. However it’s available under the new “Oracle No-Fee Terms and Conditions” (NFTC) license. The NFTC applies to the version 17 of Oracle JDK and future releases of it.
Donald Smith, Senior Director of Product Management at Oracle Corporation explained the reason for this decision: “Providing Oracle OpenJDK builds under the GPL was highly welcomed, but feedback from developers, academia, and enterprises was that they wanted the trusted, rock-solid Oracle JDK under an unambiguously free terms license, too. Oracle appreciates the feedback from the developer ecosystem and are pleased to announce, that as of Java 17 we are delivering on exactly that request.” Smith explicitly stated that the NFTC includes commercial and production use although the NFTC does not seem to highlight this fact, and that “redistribution is permitted as long as it is not for a fee.”
Oracle promises security updates for a Java LTS release under the NFTC until one year after the next LTS release is made available to the Java community. Also, the company proposed to shorten the Java LTS release cadence — from three years to just two. Additionally, security updates will be available for a total of three years. After that period, further use of the Oracle JDK in production requires a commercial license. The NFTC also covers quarterly security updates for non-LTS JDK releases. Customers can still get the Oracle JDK 17 under the commercial Oracle Java SE Subscription, paid for either ‘per user’ or ‘per CPU’. This subscription includes the Java Management Service, Advanced Management Console, GraalVM Enterprise and support. Oracle offers no commercial support for its OpenJDK distribution however.
There’s no explicit ‘cause and effect’ relationship regarding Oracle’s decision from 2018, but some surveys suggest, that Oracle’s JDK distributions are not the most popular Java distributions anymore. Developers seem to prefer OpenJDK distributions instead. For example, those from AdoptOpenJDK (now Eclipse Temurin), Amazon (Corretto JDK), Azul (Zulu), or even Microsoft to name just a few vendors. These organizations also provide commercial support on different levels for their distributions, what additionally encourages potential users to adapt alternatives in their systems to what Oracle provides.
Most interesting, as from our perspective is of course, how does this entire situation and commotion around JDKs and their different versions affect Codelab’s business and solutions being developed by us? There are, for sure quite significant factors that should be taken into consideration:
- First of all, there’s still a rather high level of uncertainty, what will happen to Oracle’s JDK itself in the future?
- Could a technological giant alter its decision once more and make a JDK ‘not free’? If so, when, and how those new regulations could look like?
- And what another change to a non-free distribution model would mean to systems/applications currently using Oracle’s Java? Would there be a need of altering JDKs?
- If so, how much effort would be needed? What bugs and potential instabilities in productional systems such change would cause?
- Even if we’ll choose to use some new, altered version of JDK (from another vendor than Oracle) should we use it only for new/greenfield projects?
- Or maybe we should consider altering JDK for already existing projects under our jurisdiction for whatever reason (e.g. security issues, stability, CPU or memory consumption etc.)?
- And last but not least: Is it even worth to consider alternative JDKs and if so — which one to choose finally?
There’s no easy, straight forward answer to any of those questions. Our approach in general is to keep in mind two key factors always necessary in Codelab’s projects: security and stability of the provided technical solutions. It could sound like a cliché at first glance, but we are working most of the time for clients from industry and automotive sectors. Especially the second one is quite demanding, in a context of quality and safety of developed solutions. And this quote is equally valid in the context of source code and devices (hardware).
Testing every possible JDK implementation, gathering comparisons and statistics by ourselves would be quite problematic. Results would vary from version to version anyway. One reasonable option is to dig through the Internet for information. A first, top level comparison could be sufficient in some cases. Made in a context of features available in each JDK from given vendor, should provide brief, condensed overview about existing JDK’s “mutations” and their features. And here’s how such comparison looks like according to researchers from Azul: JDK Comparison Matrix.
This in fact, as for today, provides most complex comparison of different JDKs and their features and support programs. Similar comparison matrix could be found out in different places of course, but Azul is one of JDK vendors, so this one is done with rather deep knowledge about the topic.
Info which could be applied to second, more sophisticated, strictly technical level of analysis is much more scattered through the Internet. In fact there’s no single page presenting one big listing of differences between JDKs in a context of features like stability, CPU and memory consumption, garbage collection behaviour or how does a given JDK-dedicated community performs, dealing with reported bugs, or just investing into JDKs future, be developing it forward. One example of quite interesting juxtaposition could be found on the amis.nl website. It might look like not so much, but in case of our systems, such specific data in hand is vital kind of info when it comes to selection of JDK most suitable for your system.
There’s yet another very important element when it comes to altering, or just updating JDK in your system(s). Nowadays (early 2022) many productional solutions still use outdated versions of JDKs (down to Java 8), because of many different aspects. The most important one is probably stability of a system – which, usually, already works on a productional environment and is in use all the time. An update, especially of such vital piece of technology as Java’s main resources is always tricky. Upgrades of JDK are almost always problematic and painful in a context of potential incompatibilities in versions. Some previously working mechanisms may stop working and even refactors in code would be required. Potential risk grows when you decide to alter a JDK by switching its implementation to be provided by different vendor now. It’s however definitely not possible to just “freeze the solution in time” because of potential security risks that need to be addressed by security patches, or general changes in given technology – e.g. Java language new features, or just technology moving forward in general.
Our recommendation how to approach to the topic of changing a JDK would be something like this:
- Determine your needs: what’s a priority – is it performance, stability, security? Or maybe something completely different?
- Gain some knowledge about differences about JDKs and do some analysis which could be a best match to your organisation’s needs?
- If possible, a good recommendation would probably be the usage of a profiler (i.e. Java Flight Recorder from Jetbrains) to determine on a “living organism” how your application behaves with a given JDK. So testing on a real solution, but of course it’s time consuming.
- Take project-like approach: do at least some brief list of risks when it comes to potential alteration of your JDK. And – to continue this thread, definitely create a backup plan.
- Also consider an approach regarding organisation vs project level. Meaning: do some analysis which projects would gain while altering the JDK? Is it possible/worth to do it for all of the systems that you develop/maintain? Again, what would be pros and cons of the approach? Should entire organisation use the same JDK?
One thing for sure: choosing a JDK is not so simple as it used to be in the past. It all depends really on your needs. In most cases similarities and differences seems to be minor ones between given implementations from other vendors. However, when things like CPU usage, memory usage, response times or garbage collection topics come to the picture (e.g. for prod. systems with a demand of high performance or reliability) topic of choosing appropriate JDK could be indeed significant.
The future of Java JDK seems to be interesting, but problematic. It’s hard to predict what Oracle, or other JDK providers will do in next years. Will there be a “winner” of this competition? Probably not. We should rather expect constant technological race between at least few different communities, responsible for developing JDKs further. But Java definitely isn’t dead and won’t be anytime soon (as we actually hear every single year).
As for now (early 2022), it looks like the most promising and stable JDKs are still provided by the industry giants like Oracle itself, Amazon (Correto JDK) and Azule (Zulu). Ironically, the situation is more complicated for projects which are now starting from the scratch — too many choices to consider. However, those three JDKs listed above, are in regards to the information scattered through the Internet have most potential to grow and last, because of great capital and the communities behind them.