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 pas­sed and in Sep­tem­ber 2021 this, quite pro­ble­ma­tic, deci­sion from the indu­stry giant was rever­sed. The Orac­le JDK is ava­ila­ble free of char­ge for pro­duc­tion use aga­in. Howe­ver it’s ava­ila­ble under the new “Orac­le No-Fee Terms and Con­di­tions” (NFTC) licen­se. The NFTC applies to the ver­sion 17 of Orac­le JDK and futu­re rele­ases of it.
Donald Smith, Senior Direc­tor of Pro­duct Mana­ge­ment at Orac­le Cor­po­ra­tion expla­ined the reason for this deci­sion: “Pro­vi­ding Orac­le OpenJDK builds under the GPL was high­ly welco­med, but feed­back from deve­lo­pers, aca­de­mia, and enter­pri­ses was that they wan­ted the tru­sted, rock-solid Orac­le JDK under an unam­bi­gu­ously free terms licen­se, too. Orac­le appre­cia­tes the feed­back from the deve­lo­per eco­sys­tem and are ple­ased to anno­un­ce, that as of Java 17 we are deli­ve­ring on exac­tly that requ­est.” Smith expli­ci­tly sta­ted that the NFTC inc­lu­des com­mer­cial and pro­duc­tion use altho­ugh the NFTC does not seem to high­li­ght this fact, and that “redi­stri­bu­tion is per­mit­ted as long as it is not for a fee.”

Orac­le pro­mi­ses secu­ri­ty upda­tes for a Java LTS rele­ase under the NFTC until one year after the next LTS rele­ase is made ava­ila­ble to the Java com­mu­ni­ty. Also, the com­pa­ny pro­po­sed to shor­ten the Java LTS rele­ase caden­ce — from three years to just two. Addi­tio­nal­ly, secu­ri­ty upda­tes will be ava­ila­ble for a total of three years. After that period, fur­ther use of the Orac­le JDK in pro­duc­tion requ­ires a com­mer­cial licen­se. The NFTC also covers quar­ter­ly secu­ri­ty upda­tes for non-LTS JDK rele­ases. Custo­mers can still get the Orac­le JDK 17 under the com­mer­cial Orac­le Java SE Sub­scrip­tion, paid for either ‘per user’ or ‘per CPU’. This sub­scrip­tion inc­lu­des the Java Mana­ge­ment Servi­ce, Advan­ced Mana­ge­ment Con­so­le, Gra­alVM Enter­pri­se and sup­port. Orac­le offers no com­mer­cial sup­port for its OpenJDK distri­bu­tion however. 

The­re­’s no expli­cit ‘cau­se and effect’ rela­tion­ship regar­ding Orac­le­’s deci­sion from 2018, but some surveys sug­gest, that Orac­le­’s JDK distri­bu­tions are not the most popu­lar Java distri­bu­tions any­mo­re. Deve­lo­pers seem to pre­fer OpenJDK distri­bu­tions inste­ad. For exam­ple, tho­se from Adop­tO­penJDK (now Eclip­se Temu­rin), Ama­zon (Cor­ret­to JDK), Azul (Zulu), or even Micro­soft to name just a few   ven­dors. The­se orga­ni­za­tions also pro­vi­de com­mer­cial sup­port on dif­fe­rent levels for the­ir distri­bu­tions, what addi­tio­nal­ly enco­ura­ges poten­tial users to adapt alter­na­ti­ves in the­ir sys­tems to what Orac­le provides.

Most inte­re­sting, as from our per­spec­ti­ve is of cour­se, how does this enti­re situ­ation and com­mo­tion aro­und JDKs and the­ir dif­fe­rent ver­sions affect Code­la­b’s busi­ness and solu­tions being deve­lo­ped by us? The­re are, for sure quite signi­fi­cant fac­tors that sho­uld be taken into consideration:

  • First of all, the­re­’s still a rather high level of uncer­ta­in­ty, what will hap­pen to Orac­le­’s JDK itself in the future?
  • Could a tech­no­lo­gi­cal giant alter its deci­sion once more and make a JDK ‘not free’? If so, when, and how tho­se new regu­la­tions could look like?
  • And what ano­ther chan­ge to a non-free distri­bu­tion model would mean to systems/applications cur­ren­tly using Orac­le­’s Java? Would the­re be a need of alte­ring JDKs?
  • If so, how much effort would be needed? What bugs and poten­tial insta­bi­li­ties in pro­duc­tio­nal sys­tems such chan­ge would cause?
  • Even if we’ll cho­ose to use some new, alte­red ver­sion of JDK (from ano­ther ven­dor than Orac­le) sho­uld we use it only for new/greenfield projects?
  • Or may­be we sho­uld con­si­der alte­ring JDK for alre­ady exi­sting pro­jects under our juris­dic­tion for wha­te­ver reason (e.g. secu­ri­ty issu­es, sta­bi­li­ty, CPU or memo­ry con­sump­tion etc.)?
  • And last but not least: Is it even worth to con­si­der alter­na­ti­ve JDKs and if so — which one to cho­ose finally?

There’s no easy, stra­ight for­ward answer to any of tho­se questions. Our appro­ach in gene­ral is to keep in mind two key fac­tors always neces­sa­ry in Codelab’s pro­jects: secu­ri­ty and sta­bi­li­ty of the pro­vi­ded tech­ni­cal solu­tions. It could sound like a cli­ché at first glan­ce, but we are wor­king most of the time for clients from indu­stry and auto­mo­ti­ve sec­tors. Espe­cial­ly the second one is quite deman­ding, in a con­text of quali­ty and safe­ty of deve­lo­ped solu­tions. And this quote is equ­al­ly valid in the con­text of sour­ce code and devi­ces (har­dwa­re).

Testing eve­ry possi­ble JDK imple­men­ta­tion, gathe­ring com­pa­ri­sons and sta­ti­stics by our­se­lves would be quite pro­ble­ma­tic. Results would vary from ver­sion to ver­sion any­way. One reaso­na­ble option is to dig thro­ugh the Inter­net for infor­ma­tion. A first, top level com­pa­ri­son could be suf­fi­cient in some cases. Made in a con­text of featu­res ava­ila­ble in each JDK from given ven­dor, sho­uld pro­vi­de brief, con­den­sed ove­rview abo­ut exi­sting JDK’s “muta­tions” and the­ir featu­res. And here­’s how such com­pa­ri­son looks like accor­ding to rese­ar­chers from Azul: JDK Com­pa­ri­son Matrix.
This in fact, as for today, pro­vi­des most com­plex com­pa­ri­son of dif­fe­rent JDKs and the­ir featu­res and sup­port pro­grams. Simi­lar com­pa­ri­son matrix could be found out in dif­fe­rent pla­ces of cour­se, but Azul is one of JDK ven­dors, so this one is done with rather deep know­led­ge abo­ut the topic.

Info which could be applied to second, more sophi­sti­ca­ted, stric­tly tech­ni­cal level of ana­ly­sis is much more scat­te­red thro­ugh the Inter­net. In fact there’s no sin­gle page pre­sen­ting one big listing of dif­fe­ren­ces betwe­en JDKs in a con­text of featu­res like sta­bi­li­ty, CPU and memo­ry con­sump­tion, gar­ba­ge col­lec­tion beha­vio­ur or how does a given JDK-dedi­ca­ted com­mu­ni­ty per­forms, dealing with repor­ted bugs, or just inve­sting into JDKs futu­re, be deve­lo­ping it for­ward. One exam­ple of quite inte­re­sting juxta­po­si­tion could be found on the amis.nl websi­te. It might look like not so much, but in case of our sys­tems, such spe­ci­fic data in hand is vital kind of info when it comes to selec­tion of JDK most suita­ble for your system.

There’s yet ano­ther very impor­tant ele­ment when it comes to alte­ring, or just upda­ting JDK in your system(s). Nowa­days (ear­ly 2022) many pro­duc­tio­nal solu­tions still use out­da­ted ver­sions of JDKs (down to Java 8), becau­se of many dif­fe­rent aspects. The most impor­tant one is pro­ba­bly sta­bi­li­ty of a sys­tem – which, usu­al­ly, alre­ady works on a pro­duc­tio­nal envi­ron­ment and is in use all the time. An upda­te, espe­cial­ly of such vital pie­ce of tech­no­lo­gy as Java­’s main reso­ur­ces is always tric­ky. Upgra­des of JDK are almost always pro­ble­ma­tic and pain­ful in a con­text of poten­tial incom­pa­ti­bi­li­ties in ver­sions. Some pre­vio­usly wor­king mecha­ni­sms may stop wor­king and even refac­tors in code would be requ­ired. Poten­tial risk grows when you deci­de to alter a JDK by swit­ching its imple­men­ta­tion to be pro­vi­ded by dif­fe­rent ven­dor now. It’s howe­ver defi­ni­te­ly not possi­ble to just “fre­eze the solu­tion in time” becau­se of poten­tial secu­ri­ty risks that need to be addres­sed by secu­ri­ty pat­ches, or gene­ral chan­ges in given tech­no­lo­gy – e.g. Java lan­gu­age new featu­res, or just tech­no­lo­gy moving for­ward in general.

Our recom­men­da­tion how to appro­ach to the topic of chan­ging a JDK would be some­thing like this:

  • Deter­mi­ne your needs: what’s a prio­ri­ty – is it per­for­man­ce, sta­bi­li­ty, secu­ri­ty? Or may­be some­thing com­ple­te­ly different?
  • Gain some know­led­ge abo­ut dif­fe­ren­ces abo­ut JDKs and do some ana­ly­sis which could be a best match to your organisation’s needs?
  • If possi­ble, a good recom­men­da­tion would pro­ba­bly be the usa­ge of a pro­fi­ler (i.e. Java Fli­ght Recor­der from Jet­bra­ins) to deter­mi­ne on a “living orga­nism” how your appli­ca­tion beha­ves with a given JDK. So testing on a real solu­tion, but of cour­se it’s time consuming.
  • Take pro­ject-like appro­ach: do at least some brief list of risks when it comes to poten­tial alte­ra­tion of your JDK. And – to con­ti­nue this thre­ad, defi­ni­te­ly cre­ate a bac­kup plan.
  • Also con­si­der an appro­ach regar­ding orga­ni­sa­tion vs pro­ject level. Meaning: do some ana­ly­sis which pro­jects would gain whi­le alte­ring the JDK? Is it possible/worth to do it for all of the sys­tems that you develop/maintain? Aga­in, what would be pros and cons of the appro­ach? Sho­uld enti­re orga­ni­sa­tion use the same JDK?

One thing for sure: cho­osing a JDK is not so sim­ple as it used to be in the past. It all depends real­ly on your needs. In most cases simi­la­ri­ties and dif­fe­ren­ces seems to be minor ones betwe­en given imple­men­ta­tions from other ven­dors. Howe­ver, when things like CPU usa­ge, memo­ry usa­ge, respon­se times or gar­ba­ge col­lec­tion topics come to the pic­tu­re (e.g. for prod. sys­tems with a demand of high per­for­man­ce or relia­bi­li­ty) topic of cho­osing appro­pria­te JDK could be inde­ed significant.

The futu­re of Java JDK seems to be inte­re­sting, but pro­ble­ma­tic. It’s hard to pre­dict what Orac­le, or other JDK pro­vi­ders will do in next years. Will the­re be a “win­ner” of this com­pe­ti­tion? Pro­ba­bly not. We sho­uld rather expect con­stant tech­no­lo­gi­cal race betwe­en at least few dif­fe­rent com­mu­ni­ties, respon­si­ble for deve­lo­ping JDKs fur­ther. But Java defi­ni­te­ly isn’t dead and won’t be any­ti­me soon (as we actu­al­ly hear eve­ry sin­gle year).

As for now (ear­ly 2022), it looks like the most pro­mi­sing and sta­ble JDKs are still pro­vi­ded by the indu­stry giants like Orac­le itself, Ama­zon (Cor­re­to JDK) and Azu­le (Zulu). Iro­ni­cal­ly, the situ­ation is more com­pli­ca­ted for pro­jects which are now star­ting from the scratch — too many cho­ices to con­si­der. Howe­ver, tho­se three JDKs listed abo­ve, are in regards to the infor­ma­tion scat­te­red thro­ugh the Inter­net have most poten­tial to grow and last, becau­se of gre­at capi­tal and the com­mu­ni­ties behind them.

Sour­ces:

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­pa­ring JVM per­for­man­ce; Zulu OpenJDK, OpenJDK, Orac­le JDK, Gra­alVM CE