Oracle brengt Java 21 uit als lts-release met acht jaar ondersteuning

Oracle heeft Java 21 uitgebracht. De lts-release krijgt dit keer acht jaar ondersteuning. In JDK 21 zitten niet alleen stabiliteits- en beveiligingsupdates, maar ook nieuwe features zoals virtual threads en structured concurrency.

Oracle heeft de Java Development Kit 21 breed beschikbaar gemaakt. Het gaat om een long term release, maar wel eentje die dit keer langere ondersteuning krijgt dan gemiddeld. Oracle brengt normaal ieder half jaar een nieuwe versie van Java uit en iedere twee jaar een lts-release. JDK 21 krijgt acht jaar ondersteuning. Alle releasenotes zijn hier te vinden.

In de nieuwe versie van de populaire programmeertaal zitten meerdere grote verbeteringen. Daarvan hebben er vijftien een JDK Enhancement Proposal gekregen. Een van de verbeteringen in de taal is de toevoeging van een api voor structured concurrency. Daarmee worden verschillende taken die op verschillende threads draaien, samengevoegd en behandeld. Ook is er een nieuwe api toegevoegd voor key encapsulation. Daarmee kunnen symmetrische encryptiesleutels worden beveiligd via algoritmes als RSA-KEM. Ook zijn er virtual threads toegevoegd aan de taal waarmee applicaties die veel doorvoer hebben, makkelijker worden bijgewerkt.

Verder zit er een preview in de taal voor classes die nog geen naam hebben. Ook is de ondersteuning voor de Windows 32bit-x86-port weggehaald. In de toekomst moet dat helemaal uit de JDK verdwijnen.

Door Tijs Hofmans

Nieuwscoördinator

21-09-2023 • 14:44

51

Submitter: hastam

Reacties (51)

51
51
37
7
0
10
Wijzig sortering
Ik ben benieuwd: wordt deze JDK nog veel gebruikt? Of is zo'n beetje iedereen vanwege licentiekosten overgestapt op OpenJDK? Of gebruikt niemand Java meer 8)7 ?
Oracle is daar van teruggekomen. "JDK 21 binaries are free to use in production and free to redistribute, at no cost, under the Oracle No-Fee Terms and Conditions (NFTC)." https://www.oracle.com/java/technologies/downloads/

OpenJDK wordt veel gebruikt of een smaakje daarvan Azul Zulu, AdoptOpenJDK, Amazon Corretto, RedHat, Adoptium Temurin, IBM, BellSoft , SAP, etc.

Zelf gebruik ik Amazon Corretto en Azul Zulu

[Reactie gewijzigd door Cobalt op 22 juli 2024 13:41]

Nou nee, want er is een groot paard van Troje waar bedrijven vanaf september 2026 veel geld in mogen stoppen. In de kleine letters staat dat je straks gewoon moet dokken. En wel op basis van de Employee metric, dus ook al heb je 1 Java SE installatie in gebruik voor 1 persoon, dan mag je iedereen meetellen als gevolg van de licentie definitie:
JDK Development Kit 21 downloads
JDK 21 binaries are free to use in production and free to redistribute, at no cost, under the Oracle No-Fee Terms and Conditions (NFTC).

JDK 21 will receive updates under the NFTC, until September 2026, a year after the release of the next LTS. Subsequent JDK 21 updates will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee.
Bron: https://www.oracle.com/java/technologies/downloads/

De definitie:
Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of
Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual
number of employees that use the Programs.
For these Java SE Universal Subscription licenses, the licensed quantity purchased must, at a minimum, be equal to the number of Employees as of the effective
date of Your order. Under this Employee metric for Java SE Universal Subscription Programs(s), You may only install and/or run the Java SE Universal Subscription Program(s) on up to 50,000 Processors, If
Your use exceeds 50,000 Processors, exclusive of Processors installed and/or running on desktop and laptop computers, You must obtain an additional license from Oracle.
Bron:
https://www.oracle.com/as...ion-pricelist-5028356.pdf

[Reactie gewijzigd door Don_Gulio op 22 juli 2024 13:41]

Dit betekent NIET dat je Oracle JDK 21 alleen maar tot september 2026 gratis mag gebruiken.

Het betekent dat ze gratis updates brengen tot september 2026. Wil je daarna nog updates hebben, dan moet je Oracle betalen voor support.

Je mag het zo lang als je wilt gratis gebruiken. Dat betalen gaat alleen maar over support en updates die Oracle uitbrengt.

En als je Oracle daar niet voor wil betalen dan kun je heel makkelijk een build van OpenJDK gebruiken. Verschillende bedrijven en open source organisaties bieden builds van OpenJDK aan onder verschillende voorwaarden voor support.
Dan nog snap ik het probleem niet zo, waarom zou je je software niet gelijk overbrengen naar de volgende LTS release van de JDK? Ik snap best dat daar wat werk in kan zitten maar als je het niet doet bouw je alleen maar technical debt op. In mijn ervaring is bijhouden minder werk en minder rompslomp dan achterstallig onderhoud inhalen.
Waar, maar product owners willen functionele/business waarde. Technische schuld wegwerken levert dat niet. Ik zie overal dat teams constant moeten vechten om tijd te krijgen om technische schuld weg te werken.
Daar hoort de product owner gewoon niet over te gaan. Dat is zijn taak niet.

Als software engineer hoort het er ook bij om nee te kunnen zeggen.
Daar staat dus nu tegenover dat niemand de product owner wil zijn die de CEO moet vertellen dat er 43.000 Java licenties voor het hele bedrijf gekocht moeten worden, puur omdat jij je zaakjes niet op orde hebt.
waarom zou je je software niet gelijk overbrengen naar de volgende LTS release van de JDK
Ik denk dat je niet hebt gezien hoeveel bedrijven er wel niet nog op Java 8 vastzitten (vier LTS'en terug). Java 7 wordt ook nog gebruikt, helaas.

Erg jammer, want de JRE is nogal een stukje slimmer en sneller geworden over de jaren. Sommige onaangepaste code (specifiek code die veel objecten aanmaakt en verwijdert, wat je in Java snel doet) kan in sommige gevallen 20 tot 40 procent sneller draaien als je het op een moderne JRE draait.

Nu is vooral 8 -> 11 lastig vanwege het introduceren van modules en het weghalen van een aardig aantal API's, maar iedere versie breekt er wel iets in de compatibiliteit. Het is allemaal wel te doen, maar na een jaar of vijf/zes aan Java schrijven, zit je toch snel met een codebase die redelijk veel API's aanraakt, helemaal als je ook nog dependencies binnenhaalt.

OpenJDK 8 wordt tot 2026 nog in leven gehouden. Ik verwacht dus dat over een jaar of drie bedrijven hun uitgestelde migratie beginnen, daarna zes maanden lang in paniek zijn dat ze te weinig tijd hebben, en over een jaar of vijf echt over beginnen te komen.
wat ik in de praktijk tegen kom - mkb, tot 100 man - is dat men of wil migreren naar een nieuw systeem, of er geen budget is (business loopt minder). Zo ken ik een site die pas in 2022 is afgestapt van php 5 (na verkoop bedrijf). Ook weet ik van Windows Server 2012 installaties die men wilt uitfaseren, maar dat wil combineren met de bouw van een nieuw systeem.

Ding is dat migratie nog aardig wat werk kan kosten. Zeker als je gebruik maakt van libraries die problemen geven bij nieuwere versies.
In de praktijk werkt dat inderdaad helaas vaak zo, vaak omdat degene die de beslissingen neemt niet capabel genoeg is om de gevolgen te overzien als je het niet direct doet ("het werkt toch nog?"). Hoe langer je het uitstelt, hoe groter dat probleem wordt. Vaak zijn de veranderingen tussen opvolgende versies nog wel te overzien maar als je ineens 4 versies omhoog moet en alle libraries die je gebruikt zijn wél met hun tijd meegegaan, dan komt er ineens een bak werk op je af waar je wel bang van wordt. Maar dan heb je het ook wel echt aan jezelf te danken als bedrijf zijnde.

In het verleden heb ik zelf bij een bedrijf gewerkt als native iOS ontwikkelaar (Objective C en Swift). In de beginjaren van Swift veranderde de taal continu maar was het updaten van je code vaak een kwestie van een druk op de knop, desnoods wat handmatige aanpassingen en libraries updaten. Je raadt het al: geen tijd voor, totdat Swift 1.0 ineens niet meer ondersteund werd vanuit Apple en we voor levende projecten wel móésten updaten met alle rampzalige gevolgen, onhaalbare deadlines en kosten van dien.
In het begin gratis en later niet, staat in de regel eronder:

"JDK 21 will receive updates under the NFTC, until September 2026, a year after the release of the next LTS. Subsequent JDK 21 updates will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee."

Dus het is nog steeds hetzelfde verhaal, alleen toen Oracle Java overnam was Java8 nog steeds een grote groep die eigenlijk al over moest, maar dat niet kan (de spring van 8 naar 11 en hoger is nogal tricky met een aantal libraries)
Niemand moet over naar een nieuwere Java versie, en je kunt oudere Oracle JDK versies nog steeds gewoon gratis gebruiken. Alleen: als je na september 2026 nog updates van Oracle wilt, dan moet je daarvoor een support contract met Oracle afsluiten. Dus alleen voor updates en support, niet voor het gebruik van de Oracle JDK.

[Reactie gewijzigd door jj71 op 22 juli 2024 13:41]

Veilig kun je jdk eigenlijk alleen gebruiken als je consequent updates uitvoert. Er worden regelmatig vulnerabilities ontdekt, die meestal ook snel weer gepatched worden met een update.
98% van de tijd zijn die relevant voor Desktop usage, niet zozeer backend webapplicaties.
Hmm. Ik loop te lang mee en te murw gemept met security officers die ongepatchte software als een red-flag in een audit report zetten om nog te overwegen niet gepatchte software te draaien denk ik. Beroepsdeformatie zullen we het maar noemen. En inderdaad voorheen was het ook gebruik. Dan is men deels teruggekomen.
Blijkbaar is Java toch nog wel goed gebruikt bij grote bedrijven :
Microsoft (blijkbaar voor het ontwikkelen van Edge), Uber, LinkedIn app, Amazon, Paypal, Netflix, Airbnb, Spotify...
Eigenlijk is Java nog steeds het hart van Android. (Al is Kotlin nu "Google's preffered language")
Dit gaat niet echt over java maar over de JDK, java zelf wordt inderdaad nog enorm veel gebruikt. Maar wie het ontwikkelt en welke licenties daarbij horen gaat het hier over, niet over het gebruik van java zelf.
Klopt, maar iemand moet toch de apps ontwikkelen of verder ondersteunen ?
Wat? Dat is dus compleet niet waar dit overgaat, dit gaat niet over programmeren. Gaat gewoon over verschillende versies van java en de licenties die daarbij horen, niet waarvoor java gebruikt wordt.
Nu ben ik niet mee. Dit artikel gaat toch over een nieuwe JDK ?
En ik antwoorde gewoon op de vraag van iemand die benieuwd was of Java nog gebruikt wordt op de dag van vandaag.
Maar voel je vrij om wat meer uitleg te geven.
https://www.oracle.com/ne...eases-java-21-2023-09-19/
Eigenlijk is Java nog steeds het hart van Android. (Al is Kotlin nu "Google's preffered language")
Kotlin heeft wat tractie in de markt, vooral op Android, maar ik zie het niet als een Java-killer. Deels omdat Java een inhaalslag maakt op features (records, lichtgewicht concurrency, string templating en pattern matching in switches). Dan resteert eigenlijk alleen nog maar de taal. Die is op zich prima, maar in handen van één partij (JetBrains) die beslist over de richting van de taal en ook de enige werkbare Kotlin ontwikkelomgeving (IntelliJ) levert. Nu zijn de features van IntelliJ best goed te noemen, maar de performance is met elke release steeds slechter.

Kotlin en IntelliJ zijn in hoge mate vendor lock-in. Als je performant wilt ontwikkelen in Kotlin heb je geen alternatief. Daarnaast kan JetBrains nu alles semi-gratis weggeven en als iedereen afhankelijk is van het Kotlin ecosysteem dat grof licentiegelden gaan vragen. Net als Oracle gedaan heeft. Best een risico als je het mij vraagt.

[Reactie gewijzigd door ari3 op 22 juli 2024 13:41]

En kotlin is gewoon een variant van Java en draait nog steeds op een VM, dus eigenlijk niks nieuws.
Wat maakt het uit, er is hier ook gewoon een OpenJDK release van. Het gaat erom dat Java 21 uit is.

En ja de halve backendwereld gebruikt nog Java.
OracleJDK is niet echt interessant door de licentiekosten, maar in principe is de OpenJDK nu de standaard. Het team wat voorheen oracleJDK ontwikkelde dee al mee aan OpenJDK en volgens mij is de Oracle variant gewoon OpenJDK met een aantal packages van Oracle die je anders ook gewoon toe kan voegen via Maven of Gradle maar dan met een licentie.

Verder is er eigenlijk geen reden om OracleJDK te gebruiken. Meestal is de AdoptOpenJDK versie toereikend.
Op zich maakt dat niet zoveel uit, de versies komen gewoon overeen en Oracle werkt ook gewoon mee aan OpenJDK. OracleJDK wordt in enterprise omgevingen nog wel gebruikt icm WebLogic bijvoorbeeld. Maar dat is niet de hoofdmoot van het Java gebruik. De halve backend wereld draait op Java, dus veel gebruikt word het zeker.
Mijn werk is al 17 jaar klanten in de hele wereld te helpen met Oracle licentie vraagstukken en ken niemand die niet bezig is om van Oracle's JDK af te stappen. Of, in ieder geval uit te zoeken welke installaties een risico vormen. Alleen spugen de verschillende CMDB's en SAM tools niet de relevante variabelen weer om hier een boerenfluitjes-verstand startpunt mee te maken. Althans, niet out-of-the-box.

Voor wie wil weten hoe je een begin kan maken om door de bomen het bos te zien: Check dit webinar.
Ik heb toch verschillende opdrachtgevers die juist wel daarmee bezig zijn.
Vraagje: Ben zelf geen Oracle Java gebruiker/kenner maar zie bij ons dat alle Linux servers met Oracle Java redelijk snel waren omgezet naar OpenJDK (jaren geleden) maar dat dit aan de Windows server kant slecht lukte. Door het licentiemodel moet je toch een heel VMware cluster licentieren onder regels van toen Java betaald werd.
Is dat herkenbaar met java applicaties op Windows server?
Zou het liefst helemaal van Oracle Java af willen.
Hoe doen jullie het met Java aan de cliënt kant. Daar hebben we nu ook nog Oracle Java.
Bedankt!
Dat was zo, maar is niet meer. Oracle is overgestapt op een Employee model. Dus ook al heb je 10.000 servers en daarop staat 1 VM met Oracle JavaSE (of is er 1 werkstation met SE voor iets anders dan 'general purpose' doeleinden), dan moet je voor alle werknemers aftikken.

Denk zelf dat een rechter en de mededingingsautoriteit daar wel het zijne van zal vinden, maar wie naar Oracle's pijpen wil dansen is dus duur uit.

Uitgezonderd zijn natuurlijk Java installaties die van een fabrikant komt die een overeenkomst met Oracle heeft. Gemakshalve verstrekt Oracle die lijsten niet ;-)

[Reactie gewijzigd door Don_Gulio op 22 juli 2024 13:41]

Bedankt voor de reacties hierboven/onder.
We hebben het employee model even voor ons uit kunnen schuiven doordat we dat op tijd wisten bij verlenging. Nu hopen dat een bedrijf dit 'zeer bijzondere' model aanvecht. En geeft ons tijd om hopelijk helemaal van Oracle Java af te komen (Windows servers en een x aantal laptops).
Voor onze onprem kunnen we helaas niet een cloud licentiemodel gebruiken.
De embedded licenties die met andere sw meekomt vlaggen we in de cmdb. Veel gedoe, tot contracten van die sw lezen.

Oracle licenties kosten gewoon teveel tijd alleen al!
Het is maar wat je op tijd noemt natuurlijk ;)
Hoop dat het in dit geval geen zorg-, veiligheids-, financieel of anderzijds kritiek systeem betreft btw.
Zie niet in wat de op tijd verlengen om nog een tijdje in het oude prijsmodel te blijven te maken heeft met je 'hoop dat het geen kritiek systeem betreft'. Oeps heeft gewoon nog wat langer de tijd gekocht tegen 'laag tarief' om op zoek te gaan naar een andere JVM vendor met voordeliger tarieven (bij weinig relatief weinig installaties tov aantal personeelsleden) voor de toekomst.

Dankzij de op tijd afgesloten licentieverlenging gaat dat gewoon volledig ondersteund door Oracle.
Vergeet niet dat je ook betaalt voor alle werknemers van je leveranciers die voor je werken 🤣

Uit voorzorg maar betalen voor iedereen bij Microsoft, je weet nooit welke van hun duizenden werknemers een keer support voor je leveren 🤷‍♂️
Een mededingingsautoriteit zal zien dat er een redelijk alternatief is in de vorm van OpenJDK. Niet identiek, maar voldoende gelijkwaardig dat klanten een weloverwogen keuze kunnen maken.

Sterker nog, zelfs .Net moet je in die overweging meenemen. Microsoft heeft dat in de markt gezet als alternatief voor Java, en de VM's zijn vergelijkbare producten ook al zijn ze niet binair compatible.
Hier draaien we exclusief op Amazon Corretto https://aws.amazon.com/corretto/
Daar kan je een gepackaged OpenJDK downloaden voor Windows. En tot nu toe, is deze bijzonder stabiel en geeft geen issues (JDK11).

De OpenJDK downloaden via https://openjdk.org/ is voor Windows eigenlijk niet te doen.
+1. Maar ik wil graag een installer ;) Werkt net iets makkelijker.
Het Adoptium initiatief maakt ook installers voor de LTS-versies van de OpenJDK en ook nog eens voor alle relevante platformen, hier te downloaden: https://adoptium.net/

Deze worden gesponsord door o.a. RedHat, Canonical, Huawei, Google, Microsoft, Alibaba, Azul en IBM.

[Reactie gewijzigd door ari3 op 22 juli 2024 13:41]

Niet enkel de releases met Oracle LTS support, maar alle releases van Java kun je vinden op adoptium.net.. typisch ietsje later dan de officiele launch van de Oracle JDK build, omdat ze eerst nog druk doende zijn om de build door de testsuites te halen.
Waarom gebruik je SDKMAN! niet hiervoor? Is wel wat lastiger te installeren onder Windows zo te lezen.
Dat hangt volgens mij enkel van je leverancier af en/of die die oude meuk nog wil en/of kan supporten op de backend.

Op Citrix/TS servers zou ik sowieso ook geen Java client(s) willen hebben draaien, is dat jullie voornaamste probleem?
Op laptops/desktops zou ik het daarnaast ook niet willen aanbieden. Wel eens geprobeerd OpenJDK ofzo (EDIT: en later Amazon Corretto idd als pilot; thanks @maartsen ) als alternatief aan te bieden aan eindgebruikers, maar ze konden de (per definitie!) onveilige Web Start functionaliteit niet gebruiken voor hun middeleeuwse applicaties zonder praktisch alle overige security uit te schakelen binnen de java client. En ik gok ook Internet Explorer |:(

[Reactie gewijzigd door Ché Mig op 22 juli 2024 13:41]

Zelf ben ik geen software ontwikkelaar (meer) maar hoe zit het tegenwoordig met java en de versies?

Gaat het hier bij Oracle Java 21 om de volgende versie van de tool-keten? of bepaald Oracle hier ook meteen de versie van Java als taal? Ik bedoel dat nu alle open-java initiatieven nu ook hun taal model moeten/kunnen/gaan aanpassen?

Toegeveven, zelf lees ik Oracle-Java als de combinatie van Oracle-JDK en Oracle-JRE als geheel, maar misschien heb ik het hier mis en is Oracle-Java juist de taal-definitie.
Gaat om de JLS (Java Language Specification), de JVM Specification en een reference implementation van die twee (OpenJDK, Oracles gratis versie van Java).

Bijna alle distributies van Java zijn tegenwoordig gebaseerd op OpenJDK. Dus zo heel veel is er niet te doen voor andere vendoren.
Je hebt de Java specificatie die door Oracle beheerd wordt, de OpenJDK GPL Java tooling en de Oracle JDK die onder een wat meer restrictieve licentie valt.
Java 21 is zowel de versie van de specificatie als die van de tooling.
Vrijwel alle open Java toolchains zijn op OpenJDK gebaseerd dus die kunnen van de nieuwe tooling gebruik maken.
Zit er al even naar uit te kijken, eindelijk weer eens wat nieuwe features die niet alleen als incubator feature beschikbaar zijn. We draaien nu nog op Java 17 (ja ik weet het, nog steeds een relatieve luxe) maar ik had ook totaal geen zin om voor 18 tot 20 te pushen want er zat toch niks in wat al in productie mijn leven zou verbeteren.
Dat doet overkomen alsof het slecht is met java 17 te werken. Dit is de LTS voor 21, voor de meeste organisaties is het zeer begrijpelijk alleen LTS versies te gebruiken op productie.
Ik denk helemaal niet dat het zo overkomt op de meeste mensen. Ik zeg zelfs dat het nog een relatieve luxe is.
Record deconstruction is wel handig, al is het nog altijd zeer beperkt vergeleken met wat Scala te bieden heeft. Daarnaast pattern matching op records (instanceof dus - meestal een anti-pattern), misschien handig in combinatie met sealed types als alternatief voor visitor pattern?
Java is flink aan de weg aan het timmeren om zaken te moderniseren, toch wel goed te zien. Ik ben met name geïnteresseerd in de concurrency verbeteringen.
Tenzij je zelf heel veel concurrency managed zal het wachten zijn tot de grotere frameworks hier gebruik van gaan maken.
Het backend landschap was aardig aan het versplinteren door alle duplicatie tussen bibliotheken en 'reactive' versies er van. Benieuwd wat al die reactive projecten gaan doen, die lijken nu grotendeels overbodig. Tenzij misschien voor dingen die extreem goed moeten performen, maar de prijs die je betaalt in de vorm van al je code herschrijven en slecht leesbaar maken is wel heel hoog...

Op dit item kan niet meer gereageerd worden.