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 Septem­ber 2021 this, quite prob­lem­at­ic, decision from the industry giant was reversed. The Oracle JDK is avail­able free of charge for pro­duc­tion use again. How­ever it’s avail­able under the new “Oracle No-Fee Terms and Con­di­tions” (NFTC) license. The NFTC applies to the ver­sion 17 of Oracle JDK and future releases of it.
Don­ald Smith, Seni­or Dir­ect­or of Product Man­age­ment at Oracle Cor­por­a­tion explained the reas­on for this decision: “Provid­ing Oracle Open­JDK builds under the GPL was highly wel­comed, but feed­back from developers, aca­demia, and enter­prises was that they wanted the trus­ted, rock-sol­id Oracle JDK under an unam­bigu­ously free terms license, too. Oracle appre­ci­ates the feed­back from the developer eco­sys­tem and are pleased to announce, that as of Java 17 we are deliv­er­ing on exactly that request.” Smith expli­citly stated that the NFTC includes com­mer­cial and pro­duc­tion use although the NFTC does not seem to high­light this fact, and that “redis­tri­bu­tion is per­mit­ted as long as it is not for a fee.”

Oracle prom­ises secur­ity updates for a Java LTS release under the NFTC until one year after the next LTS release is made avail­able to the Java com­munity. Also, the com­pany pro­posed to shorten the Java LTS release cadence — from three years to just two. Addi­tion­ally, secur­ity updates will be avail­able for a total of three years. After that peri­od, fur­ther use of the Oracle JDK in pro­duc­tion requires a com­mer­cial license. The NFTC also cov­ers quarterly secur­ity updates for non-LTS JDK releases. Cus­tom­ers can still get the Oracle JDK 17 under the com­mer­cial Oracle Java SE Sub­scrip­tion, paid for either ‘per user’ or ‘per CPU’. This sub­scrip­tion includes the Java Man­age­ment Ser­vice, Advanced Man­age­ment Con­sole, GraalVM Enter­prise and sup­port. Oracle offers no com­mer­cial sup­port for its Open­JDK dis­tri­bu­tion however. 

There’s no expli­cit ‘cause and effect’ rela­tion­ship regard­ing Oracle’s decision from 2018, but some sur­veys sug­gest, that Oracle’s JDK dis­tri­bu­tions are not the most pop­u­lar Java dis­tri­bu­tions any­more. Developers seem to prefer Open­JDK dis­tri­bu­tions instead. For example, those from Adop­tOpen­JDK (now Eclipse Temur­in), Amazon (Cor­retto JDK), Azul (Zulu), or even Microsoft to name just a few   vendors. These organ­iz­a­tions also provide com­mer­cial sup­port on dif­fer­ent levels for their dis­tri­bu­tions, what addi­tion­ally encour­ages poten­tial users to adapt altern­at­ives in their sys­tems to what Oracle provides.

Most inter­est­ing, as from our per­spect­ive is of course, how does this entire situ­ation and com­mo­tion around JDKs and their dif­fer­ent ver­sions affect Codelab’s busi­ness and solu­tions being developed by us? There are, for sure quite sig­ni­fic­ant factors that should be taken into consideration:

  • First of all, there’s still a rather high level of uncer­tainty, what will hap­pen to Oracle’s JDK itself in the future?
  • Could a tech­no­lo­gic­al giant alter its decision once more and make a JDK ‘not free’? If so, when, and how those new reg­u­la­tions could look like?
  • And what anoth­er change to a non-free dis­tri­bu­tion mod­el would mean to systems/applications cur­rently using Oracle’s Java? Would there be a need of alter­ing JDKs?
  • If so, how much effort would be needed? What bugs and poten­tial instabil­it­ies in pro­duc­tion­al sys­tems such change would cause?
  • Even if we’ll choose to use some new, altered ver­sion of JDK (from anoth­er vendor than Oracle) should we use it only for new/greenfield projects?
  • Or maybe we should con­sider alter­ing JDK for already exist­ing pro­jects under our jur­is­dic­tion for whatever reas­on (e.g. secur­ity issues, sta­bil­ity, CPU or memory con­sump­tion etc.)?
  • And last but not least: Is it even worth to con­sider altern­at­ive JDKs and if so — which one to choose finally?

There’s no easy, straight for­ward answer to any of those ques­tions. Our approach in gen­er­al is to keep in mind two key factors always neces­sary in Codelab’s pro­jects: secur­ity and sta­bil­ity of the provided tech­nic­al solu­tions. It could sound like a cliché at first glance, but we are work­ing most of the time for cli­ents from industry and auto­mot­ive sec­tors. Espe­cially the second one is quite demand­ing, in a con­text of qual­ity and safety of developed solu­tions. And this quote is equally val­id in the con­text of source code and devices (hard­ware).

Test­ing every pos­sible JDK imple­ment­a­tion, gath­er­ing com­par­is­ons and stat­ist­ics by ourselves would be quite prob­lem­at­ic. Res­ults would vary from ver­sion to ver­sion any­way. One reas­on­able option is to dig through the Inter­net for inform­a­tion. A first, top level com­par­is­on could be suf­fi­cient in some cases. Made in a con­text of fea­tures avail­able in each JDK from giv­en vendor, should provide brief, con­densed over­view about exist­ing JDK’s “muta­tions” and their fea­tures. And here’s how such com­par­is­on looks like accord­ing to research­ers from Azul: JDK Com­par­is­on Mat­rix.
This in fact, as for today, provides most com­plex com­par­is­on of dif­fer­ent JDKs and their fea­tures and sup­port pro­grams. Sim­il­ar com­par­is­on mat­rix could be found out in dif­fer­ent places of course, but Azul is one of JDK vendors, so this one is done with rather deep know­ledge about the topic.

Info which could be applied to second, more soph­ist­ic­ated, strictly tech­nic­al level of ana­lys­is is much more scattered through the Inter­net. In fact there’s no single page present­ing one big list­ing of dif­fer­ences between JDKs in a con­text of fea­tures like sta­bil­ity, CPU and memory con­sump­tion, garbage col­lec­tion beha­viour or how does a giv­en JDK-ded­ic­ated com­munity per­forms, deal­ing with repor­ted bugs, or just invest­ing into JDKs future, be devel­op­ing it for­ward. One example of quite inter­est­ing jux­ta­pos­i­tion could be found on the amis.nl web­site. It might look like not so much, but in case of our sys­tems, such spe­cif­ic data in hand is vital kind of info when it comes to selec­tion of JDK most suit­able for your system.

There’s yet anoth­er very import­ant ele­ment when it comes to alter­ing, or just updat­ing JDK in your system(s). Nowadays (early 2022) many pro­duc­tion­al solu­tions still use out­dated ver­sions of JDKs (down to Java 8), because of many dif­fer­ent aspects. The most import­ant one is prob­ably sta­bil­ity of a sys­tem – which, usu­ally, already works on a pro­duc­tion­al envir­on­ment and is in use all the time. An update, espe­cially of such vital piece of tech­no­logy as Java’s main resources is always tricky. Upgrades of JDK are almost always prob­lem­at­ic and pain­ful in a con­text of poten­tial incom­pat­ib­il­it­ies in ver­sions. Some pre­vi­ously work­ing mech­an­isms may stop work­ing and even refact­ors in code would be required. Poten­tial risk grows when you decide to alter a JDK by switch­ing its imple­ment­a­tion to be provided by dif­fer­ent vendor now. It’s how­ever def­in­itely not pos­sible to just “freeze the solu­tion in time” because of poten­tial secur­ity risks that need to be addressed by secur­ity patches, or gen­er­al changes in giv­en tech­no­logy – e.g. Java lan­guage new fea­tures, or just tech­no­logy mov­ing for­ward in general.

Our recom­mend­a­tion how to approach to the top­ic of chan­ging a JDK would be some­thing like this:

  • Determ­ine your needs: what’s a pri­or­ity – is it per­form­ance, sta­bil­ity, secur­ity? Or maybe some­thing com­pletely different?
  • Gain some know­ledge about dif­fer­ences about JDKs and do some ana­lys­is which could be a best match to your organisation’s needs?
  • If pos­sible, a good recom­mend­a­tion would prob­ably be the usage of a pro­filer (i.e. Java Flight Record­er from Jet­brains) to determ­ine on a “liv­ing organ­ism” how your applic­a­tion behaves with a giv­en JDK. So test­ing on a real solu­tion, but of course it’s time consuming.
  • Take pro­ject-like approach: do at least some brief list of risks when it comes to poten­tial alter­a­tion of your JDK. And – to con­tin­ue this thread, def­in­itely cre­ate a backup plan.
  • Also con­sider an approach regard­ing organ­isa­tion vs pro­ject level. Mean­ing: do some ana­lys­is which pro­jects would gain while alter­ing the JDK? Is it possible/worth to do it for all of the sys­tems that you develop/maintain? Again, what would be pros and cons of the approach? Should entire organ­isa­tion use the same JDK?

One thing for sure: choos­ing a JDK is not so simple as it used to be in the past. It all depends really on your needs. In most cases sim­il­ar­it­ies and dif­fer­ences seems to be minor ones between giv­en imple­ment­a­tions from oth­er vendors. How­ever, when things like CPU usage, memory usage, response times or garbage col­lec­tion top­ics come to the pic­ture (e.g. for prod. sys­tems with a demand of high per­form­ance or reli­ab­il­ity) top­ic of choos­ing appro­pri­ate JDK could be indeed significant.

The future of Java JDK seems to be inter­est­ing, but prob­lem­at­ic. It’s hard to pre­dict what Oracle, or oth­er JDK pro­viders will do in next years. Will there be a “win­ner” of this com­pet­i­tion? Prob­ably not. We should rather expect con­stant tech­no­lo­gic­al race between at least few dif­fer­ent com­munit­ies, respons­ible for devel­op­ing JDKs fur­ther. But Java def­in­itely isn’t dead and won’t be any­time soon (as we actu­ally hear every single year).

As for now (early 2022), it looks like the most prom­ising and stable JDKs are still provided by the industry giants like Oracle itself, Amazon (Cor­reto JDK) and Azule (Zulu). Iron­ic­ally, the situ­ation is more com­plic­ated for pro­jects which are now start­ing from the scratch — too many choices to con­sider. How­ever, those three JDKs lis­ted above, are in regards to the inform­a­tion scattered through the Inter­net have most poten­tial to grow and last, because of great cap­it­al and the com­munit­ies behind them.

Sources:

https://blogs.oracle.com/java/post/free-java-license

https://www.infoq.com/news/2021/10/oracle-jdk-free-again/

http://azul.com/products/jdk-comparison-matrix/

http://medium.com/@javachampions/java-is-still-free‑3–0‑0-ocrt-2021-bca75c88d23b

https://developer.okta.com/blog/2019/01/16/which-java-sdk

Com­par­ing JVM per­form­ance; Zulu Open­JDK, Open­JDK, Oracle JDK, GraalVM CE