Oracle stelt Java 17 beschikbaar en belooft elke twee jaar nieuwe lts-releases

Oracle heeft de beschikbaarheid van Java 17 aangekondigd. Het gaat om een long-term-supportrelease met tal van wijzigingen en verbeteringen. Komende lts-releases komen elke twee in plaats van drie jaar beschikbaar.

Oracle heeft het over 'duizenden' bugfixes en verbeteringen voor prestaties en de stabiliteit die het bij versie 17 van Java heeft doorgevoerd. Daarnaast zijn er veertien JDK Enhancement Proposals, onder andere voor verbeterde interoperabiliteit met pseudo-willekeurigenummergenerators en voor ondersteuning van Apples macOS/AArch64-platform. Met de macOS/AArch64-port kunnen Java-applicaties op Apple-systemen met een M-soc draaien.

De vorige lts-release was Java 11 en sinds die release zijn er zeventig JDK Enhancement Proposals doorgevoerd, aldus Oracle. Het bedrijf maakt bekend dat Oracle JDK 17 en toekomstige versies van de JDK beschikbaar komen onder een free-to-use licentie. Deze blijft geldig tot een jaar na de daarop volgende lts-release. De Oracle OpenJDK-releases blijven beschikbaar onder een GPL, de licentie waar die releases al sinds 2017 onder vallen.

Gebruikers kunnen tot en met september 2029 beveiligingsupdates en bugfixes verwachten voor Oracle JDK 17. De volgende lts-release is Java 21, dat in september 2023 verschijnt. Daarmee brengt Oracle niet langer elke drie jaar lts-releases uit voor Java, maar elke twee jaar. Iedere zes maanden verschijnen nieuwe Java-releases.

Reacties (39)

[Cobalt]

Het artikel legt de nadruk op Apple "Daarnaast zijn er veertien JDK Enhancement Proposals, onder andere voor verbeterde interoperabiliteit met pseudo-willekeurigenummergenerators en voor ondersteuning van Apples macOS/AArch64-platform. Met de macOS/AArch64-port kunnen Java-applicaties op Apple-systemen met een M-soc draaien."

Het coole aan JDK 17 zijn juist alle nieuwe syntax features. Niet meer hoeven casten bij instanceof

if (shape instanceof Circle s) {
return 2 * s.radius() * Math.PI;
}

en ook bij switches

public static double getPerimeter(Shape shape) throws IllegalArgumentException {
return switch (shape) {
case Rectangle r -> 2 * r.length() + 2 * r.width();
case Circle c -> 2 * c.radius() * Math.PI;
default -> throw new IllegalArgumentException("Unrecognized shape");
};
}

Of records

record Rectangle(double length, double width) { }

En compact constructors

record Rectangle(double length, double width) {
public Rectangle {
if (length <= 0 || width <= 0) {
}
}
}

Compactere switch statements

switch (day) {
case MONDAY, FRIDAY, SUNDAY -> numLetters = 6;
case TUESDAY -> numLetters = 7;

Sealed classes, var en nog veel meer

Java Language Changes

[Reactie gewijzigd door Cobalt op 23 juli 2024 01:44]

[sys64738]

Allemaal hele mooie features die je code veel simpeler/eleganter kunnen maken. Maar uiteraard zijn het ook allemaal features die in andere talen al gemeengoed zijn. Het motto is tegenwoordig: beter goed gepikt dan slecht bedacht.

Of veel mensen binnenkort van deze nieuwe features kunnen profiteren is trouwens ook nog maar de vraag. Veel bedrijven die ik zie zitten nog op java 8. Migreren naar nieuwe java versies heeft niet enorm veel prioriteit, merk ik vaak.

[CyBeRSPiN]

Java 8 is de laatste "zure appel" om door te bijten volgens mij. Ze zijn met een reden over gegaan op veel frequentere releases zodat ze makkelijker te behappen zijn qua breaking changes.

[sys64738]

Klopt. Die kortere release cycles zijn veel beter. Voor grote bedrijven helpt dit echter niet want als er geen LTS op staat, komt het er niet in. En dan zit je weer met een vergelijkbaar lange release cycle.

Je zou die cyclus natuurlijk kunnen doorbreken door juist wel bij te blijven met de laatste java versie en iedere keer die kleinere upgrades meenemen. Dan heb je support en the-latest-and-greatest. Maar vaak is dit een lastige stap en in alle eerlijkheid zijn er meestal grotere problemen te tackelen dan nieuwe language features op kunnen/zullen lossen.

[Cobalt]

Java 8 naar nieuwer is de moeilijke overstap daarna wordt het makkelijker tot JEE9. Eclipse heeft javax naar jakarta hernoemt. Dat is een breaking change voor bijv. Spring.

[Tjeerd]

Allemaal hele mooie features die je code veel simpeler/eleganter kunnen maken. Maar uiteraard zijn het ook allemaal features die in andere talen al gemeengoed zijn. Het motto is tegenwoordig: beter goed gepikt dan slecht bedacht.

Zelf ontwikkel ik ondertussen grotendeels in Java de afgelopen 15 jaar en alhoewel deels een krachtige taal en syntax e.d., vind ik het nog altijd een omslachtige taal om dingen voor elkaar te krijgen. Het is wel beter geworden, maar er zijn veel talen die met eenvoudigere syntax leesbaarder en beheersbaarder zijn. Alhoewel het mijn werk is, is Java niet heilig voor mij en zeker niet altijd de beste taal. Maar gelukkig begint Java er steeds meer op te lijken en pikken ze de beste dingen van andere talen eruit.

[YopY]

Upgraden van grote software is eng, zeker als ze tientallen / honderden applicaties hebben draaien.

Tegenwoordig gaan we richting containerization zodat een deployment meer een 'black box' is en elke applicatie zijn eigen JVM kan hebben, maar het merendeel van Java was nog op bare metal en van die application servers.

[Argantonis]

Veel van deze dingen zaten al in vorige releases. Het enige nieuwe van de dingen die je noemt in Java 17 is die pattern matching voor instanceof die nu ook in switches zit (maar nog als preview feature), en sealed classes wat nu eindelijk geen preview feature meer is.

[tmfh]

De records, instanceof en pattern matching van switches zijn features die al in Java 16 zaten. Misschien hebben ze daarom hier minder aandacht aan gegeven.

[Transportman]

Dat zal allemaal binnenkort wel in een Plus artikel verschijnen.

[Cobalt]

Het is wel een beetje flauw om Transportman een -1 te geven.

[YopY]

Fijne features, die maken het toch weer een stukje makkelijker voor developers. Doet me denken aan Typescript, die het type van een variabele binnen een conditie kan aannemen (bijvoorbeeld dat een variabele niet "undefined" kan zijn als het binnen een "if (var !== undefined)" blok staat).

Die -> syntax in een switch, betekent dat dat er geen impliciete fallthrough is (en je dus geen break of return hoeft te doen)? Veel programmeertalen tegenwoordig hebben al geen impliciete fallthrough meer, zeker niet sinds die Apple bug (nieuws: Apple dicht groot ssl-gat in OS X). Fake edit: ik zie dat dat niet door een switch fallthrough kwam, maar door optionele blokken rondom if / else.

[GertMenkel]

Als er elke twee jaar een LTS uitkomt, hoe lang is dan de L van LTS? Zal iedere versie ook acht jaar ondersteuning krijgen zoals Java 17? En, aangezien het Oracle betreft, zal de open versie net zo lang ondersteund worden als de gelicenceerde versie?

[Cobalt]

Ja, de volgende LTS heeft ook 8 jaar support. https://www.oracle.com/ja...a-se-support-roadmap.html En Oracle geeft langer support. JDK 8 tot 2030 terwijl OpenJDK projecten dat tot 2026 doen AdoptJDK Amazon Corretto RedHat.

[Reactie gewijzigd door Cobalt op 23 juli 2024 01:44]

[elmuerte]

De 8 jaar Oracle LTS updates zijn niet gratis, je moet een support contract afsluiten wil je die periode het recht hebben om de binary the downloaden. De OpenJDK builds van Adoptium, RedHat, Azul blijven gratis voor de hele periode dat ze de LTS ondersteunen. Bij Azul is dat ook 8 jaar, en dat zonder support contract.

[Robtimus]

De Oracle LTS versie misschien niet, maar je hebt tegenwoordig meerdere OpenJDK implementaties. Zelf gebruik ik Adoptium, de opvolger van AdoptOpenJDK. Daarnaast heb je nog de grotere partijen zoals Amazon, Microsoft en Red Hat met hun eigen versies. Zie https://en.wikipedia.org/wiki/OpenJDK voor een wat groter overzicht.

[Clueless]

Die informatie staat op de Oracle Java SE Support Roadmap.

Voor Java 17 is dat dit:
GA Date: September 2021
Premier Support Until: September 2026 or later
Extended Support Until: September 2029 or later

Zolang je bereid bent om geld voor Oracle uit te trekken kun je dus inderdaad 8 jaar commerciële support krijgen. Ik vermoed dat nieuwe builds van die LTS'en ook wel naar de OpenJDK zullen komen; support is echter een ander verhaal denk ik.

[CAPSLOCK2000]

Als er elke twee jaar een LTS uitkomt, hoe lang is dan de L van LTS? Zal iedere versie ook acht jaar ondersteuning krijgen zoals Java 17? En, aangezien het Oracle betreft, zal de open versie net zo lang ondersteund worden als de gelicenceerde versie?

Van Oracle verwacht ik dat wel. Je kan er veel over zeggen maar niet dat ze geen langdurige ondersteuning bieden. Het kan een flinke cent kosten maar je kan heel lang support krijgen.

[Aaargh!]

Cool, Dan loopt Android nu 9 Java versies achter

[Killemov]

Android gebruikt geen Java maar iets wat er heel sterk op lijkt.

[Aaargh!]

Nee, android gebruikt Java. Code wordt gecompileerd door de Java compiler naar Java bytecode. Vervolgens wordt deze Java bytecode weer geconverteerd naar Google's formaat. Ze gebruiken dus niet de JVM maar wel de Java programmeertaal.

[gimbal]

Is dat met Kotlin nog steeds waar? Kotlin op de PC is een JVM taal, maar Google heeft tot nu toe altijd apart gebruik gemaakt van het Java ecosysteem. Wel de taal maar niet de runtime.

[Aaargh!]

Kotlin is een JVM taal en compiled dus naar Java bytecode. Dus met Kotlin gebruik je niet de Java taal, compiler of runtime, maar een van de tussenstappen is nog steeds Java bytecode. Ook programmeer je natuurlijk voor een groot deel tegen Java API's (en Java libraries), ook al is dit niet de implementatie van Oracle. Je zit met Kotlin dus nog steeds in het Java ecosysteem.

[Reactie gewijzigd door Aaargh! op 23 juli 2024 01:44]

[RxTweak]

Neemt de waarde van kotlin niet verder af met de release van java 17?

[Aaargh!]

Niet echt. Java is nog steeds erg verbose en Kotlin is een duidelijke verbetering.

[YopY]

Bedoel je de programmeertaal of de JVM (Dalvik)?

[uiltje]

Uh, nee, zie bijvoorbeeld de informatie op StackOverflow. Java 11 language features worden al een tijdje ondersteund, API gat wordt gedicht door de stappen richting OpenJDK.

Je hebt zelfs Java 11 nodig voor de laatste Gradle plugin.

[Reactie gewijzigd door uiltje op 23 juli 2024 01:44]

[Aaargh!]

Een aantal language features van Java 11 worden ondersteund, simpelweg omdat hier geen verandering in de bytecode voor nodig is. Nieuwe API's en het module systeem worden niet ondersteund.

[Reactie gewijzigd door Aaargh! op 23 juli 2024 01:44]

[enver63]

Maar voor Android applicaties gebruik je natuurlijk Kotlin in plaats van Java.

Voor andere projecten ga ik waar mogelijk ook afstappen van Java. In Google App Engine kun je ook Go of Node of Python gebruiken (of PHP, maar dat is geen programmeertaal ).

[SPee]

Vele Enterprise applicaties ook

[CyBeRSPiN]

Het bedrijf maakt bekend dat Oracle JDK 17 en toekomstige versies van de JDK beschikbaar komen onder een free-to-use licentie. Deze blijft geldig tot een jaar na de daarop volgende lts-release.

Dit lijkt toch wel een andere wind die is gaan waaien bij Oracle. Dus als ik het goed begrijp mag je vanaf de Oracle 17 LTS JDK gratis (free-to-use) gebruiken zolang je maar binnen een jaar na de volgende LTS overgaat naar de dan laatste LTS?

[xfj]

Dan moet je dus wel zorgen dat in je hele productie constant de nieuwste LTS van Oracle staat en anders zit je mogelijk in licentieproblemen met Oracle. Dus ik zou gewoon OpenJDK blijven gebruiken.

[CAPSLOCK2000]

Het bedrijf maakt bekend dat Oracle JDK 17 en toekomstige versies van de JDK beschikbaar komen onder een free-to-use licentie. Deze blijft geldig tot een jaar na de daarop volgende lts-release. De Oracle OpenJDK-releases blijven beschikbaar onder een GPL, de licentie waar die releases al sinds 2017 onder vallen.

Ik blijf dus maar bij OpenJDK. Zo'n free-to-use licentie klinkt aardig maar geeft geen zekerheid, dat kunnen ze op ieder moment weer veranderen. Aangezien de licentie maar 3 jaar gratis is vind ik het zelfs riskant. Ik heb maar weinig IT-projecten gezien die netjes iedere 2 jaar een major upgraden doen. Het gebeurt wel hoor, maar de kans dat het niet gebeurt/uitloopt is nogal groot. Als je wat meer systemen hebt durf ik bijna te garanderen dat ook bij zitten met achterstallig onderhoud.
Dus wat moet je dan na 3 jaar? Dan toch maar een licentie kopen? Of zonder patches doordraaien en hopen dat Oracle geen rekening stuurt?

[Zidane007nl]

Hier blijven we ook Eclipse Temurin (voorheen AdoptOpenJDK) gebruiken.

Toen Oracle een aantal jaar geleden hun licentie wijziging aankondigde zijn we helemaal afgestapt van Oracle JDK en AdoptOpenJDK (nu dan Eclipse Temurin) gaan gebruiken. Vooral vanwege de langere ondersteuning. We gaan nu niet meer terug.

[itcouldbeanyone]

Hmm komt er ook een solaris sparc release ?.
Gebruik nog veel oudere java versies omdat zaken zoals ilom & fabric-os niet willen werken met nieuwere varianten

[bzzzt]

Vanaf Java 15 is die support vervallen: https://openjdk.java.net/jeps/381
Sparc systemen worden al jaren alleen nog maar worden verkocht voor een paar klanten die per se op Sparc moeten draaien en daar een absolute hoofdprijs voor over hebben; voor nieuwe software is het al lang geen relevant platform meer. Denk ook niet dat mijn oude Ultra een geschikt platform voor Java 17 is

[Robtimus]

Oracle heeft ook de javadoc tool, en daarmee hun eigen online API, uitgebreid. Zo hebben ze nu een eigen ingebouwde "what's new": https://docs.oracle.com/e...17/docs/api/new-list.html.

[Zidane007nl]

Ik vind dit overzicht toch fijner: https://javaalmanac.io/jdk/17/apidiff/11/.

[Robtimus]

Die ziet er inderdaad overzichtelijker uit. Het zou alleen fijn zijn als je daarin a) delen kon inklappen, en b) kon filteren. Ik zal eens feedback achterlaten op de site.