Oracle brengt Java 23 uit met twaalf JDK Enhancement-voorstellen

Oracle heeft Java 23 uitgebracht, dat prestaties en runtime verbetert. Ook zijn er een aantal verbeteringen toegevoegd, waaronder twaalf zogenaamde JDK Enhancement Proposals, of jeps. Veel van de verbeteringen zijn echt alleen nog als preview beschikbaar.

Java 23 is een feature-release, die zeker zes maanden ondersteuning krijgt van Oracle, zo schrijft Oracle in een aankondiging. Alle releasenotes van Java 23 zijn hier te vinden. In maart 2025 verschijnt Java 24, waarmee de ondersteuning voor deze versie weer vervalt.

Java 23 komt met diverse nieuwe taalfeatures. Zo is er een preview uitgebracht voor 'Primitive Types in Pattern'. Hiermee worden diverse restricties voor primitieve types in pattern matching verwijderd. Ook wordt het hiermee mogelijk om instanceof en switch te gebruiken.

Verder verschijnt een derde preview van 'Implicity Declared Classes and Instance Main Methods'. Deze preview bouwt verder op previews uit Java 21 en 22, met als doel om Java te vereenvoudigen voor beginners. Concreet moet deze verbetering ervoor zorgen dat beginners hun eerste Java-programma's kunnen schrijven, zonder dat ze eerst features moeten leren kennen die bedoeld zijn voor grotere en complexere programma's.

Module import declarations, dat ook in preview is, laat ontwikkelaars packages die door een module geëxporteerd zijn, importeren zonder dat de importcode in de module aanwezig moet zijn. Verder zijn er updates rondom libraries, zoals de derde preview van Structured Concurrency, waarmee groepen van gerelateerde taken in verschillende threads geconsolideerd worden.

Door Eveline Meijer

Nieuwsredacteur

19-09-2024 • 07:46

36

Submitter: robin1979

Reacties (36)

36
36
16
0
0
14
Wijzig sortering
Hmm. Wat taal-features betreft weinig nieuws, moet ik zeggen. Behalve een paar kleine aanpassingen aan de standaardbibliotheek en de mogelijkheid Markdown in Javadocs te gebruiken, zijn er alleen maar preview-features en incubators. En die kun je in productie eigenlijk niet gebruiken, want in de praktijk veranderen ze ten opzichte van de uiteindelijke versie nog behoorlijk of vallen helemaal weg.

En wat dat wegvallen betreft, dat is een andere nieuwigheid aan deze nieuwe versie. Na al die jaren heeft Java nog steeds geen string interpolation. Er gloorde hoop aan de horizon in de vorm van string templates. Maar de string template preview is in deze versie stilletjes verwijderd. Back to the drawing board.
Ik zou in productie sowieso nooit non LTS versies runnen, behalve als je graag elk half jaar uw Java versie gaat verhogen.
Van de 'Implicity Declared Classes and Instance Main Methods' ben ik niet direct fan. Dat lijkt me alleen maar voor meer verwarring te gaan zorgen en zorgt ervoor dat mensen net minder weten hoe alles deftig in elkaar zit. Uiteindelijk is het nu niet dat je daar zelf zoveel type werk moet gaan insteken, dat doet de IDE toch allemaal voor jou.
Van de 'Implicity Declared Classes and Instance Main Methods' ben ik niet direct fan.
Je ziet dat ze afkijken van C#:
Here's a Program.cs file that is a complete C# program in C# 10:
Console.WriteLine("Hello World!");
Die natuurlijk weer de concurrentie aangaat met Python. Want je ziet dat C# en Java hard aan populariteit verliest onder jongeren, omdat ze in Python wel gelijk resultaat zien met een paar regels code. Vooral nu je via ChatGPT/Copilot het automatisch kan laten genereren.
Vind het als startup class ook wel prima zo dat al die boilerplate er niet rond staat. Daar heb je verder helemaal niets aan namelijk.
[...]

Je ziet dat ze afkijken van C#:

[...]

Die natuurlijk weer de concurrentie aangaat met Python. Want je ziet dat C# en Java hard aan populariteit verliest onder jongeren, omdat ze in Python wel gelijk resultaat zien met een paar regels code. Vooral nu je via ChatGPT/Copilot het automatisch kan laten genereren.
Bedenk ook dat Java/C# vooral in enterprise gebruikt worden, en dat dat gewoon een saai segment is om in te werken doorgaans.

Daarnaast zijn er steeds meer type-safe en memory/resource-safe talen die niet naar een VM met een GC compileren maar rechtstreeks naar native, bv Rust en Zig.

Ook is het zo dat hoewel GC verbeterd is in de laatste 10 jaar, het nog steeds problematisch kan zijn in termen van GC latency en throughput.
Er zijn genoeg blogs te vinden van allerlei grote enterprises die bv software van Go naar Rust herschrijven, niet omdat ze Rust zo tof vinden (vast ook wel) maar omdat Go met z'n garbage collector gewoon niet de performance properties kan bieden die ze nodig hebben. Met name latency spikes zijn een enorm probleem als je opschaalt.

Als je dat ziet gebeuren als nieuwe software dev, dan moet je bijzonder in elkaar zitten om dan te zeggen "ja Java of C# is een goede keus voor mij nu".

Daarnaast klopt oom wat je zei, python is heel populair nu, vooral om neural network architecturen mee te klussen beschrijven.

[Reactie gewijzigd door Jeanpaul145 op 21 september 2024 18:37]

Same ik ook eerlijk gezegd niet, maar dit is het gevolg omdat er nogal een grote groep die vind dat java teveel boilerplate is. Vind dat persoonlijk wat Java eenvoudig te lezen maakt, maar goed…

Blijf zelf ook altijd op de lts versies, deze feature releases zijn leuk vooral voor Oracle om snel wat feedback te krijgen uit the wild volgend mij, maar voor productie zou ik ze verder niet gebruiken. Veel spannends zit er meestal niet in(qua feature complete that is).

[Reactie gewijzigd door Powerblast op 19 september 2024 09:13]

Persoonlijk zou ik juist gewoon de laatste versie gebruiken. Dat doe je met je andere dependencies toch ook? Spring/Quarkus/whatever... en die hebben doorgaans beduidend meer breaking changes dan een nieuwe JDK. JDK updaten kost wel iets meer moeite qua infra natuurlijk, maar in een moderne (container-)omgeving valt dat tegenwoordig ook erg mee, dan komt het neer op een paar nummertjes ophogen hier en daar.
Hier is het N-1 of N-2, waarbij N de laatste versie is. Teveel geneuzel met nieuwe versies en fine-tuning en andere 'oops' effecten.
Bijzonder wel - vaak hoor je dat management/architecten het niet aandurven om JDKs toe te staan die 'unsupported' zijn. Maar ik snap jullie wel. Mocht er toch een keer een serieus (security)-issue komen bovendrijven waardoor je per se wil upgraden, dan kan dat alsnog. Ten minste, ik neem aan dat dat ongeveer het idee erachter is.

Hier is het beleid "zolang het maar een LTS-versie is die niet EoL is." Dus het ene team mag rustig een drie jaar oude JDK gebruiken en het andere wil graag up to date zijn maar mag dat dus niet. Best krom.

[Reactie gewijzigd door Inaldt op 19 september 2024 13:37]

Voor niet core IT mag je doen wat je wil, maar het deel waar geld mee verdiend wordt kent strengere spelregels.
Ik zou in productie sowieso nooit non LTS versies runnen
Misschien een stomme vraag, maar waarvoor denk jij dan dat non LTS versies wel bedoeld zijn?
Hoe ik het zie: voor enthousiastelingen die er thuis wat mee willen doen en voor bedrijven om al eens een preview te krijgen van wat er in de LTS zit aan te komen.
voor enthousiastelingen die er thuis wat mee willen doen en voor bedrijven om al eens een preview te krijgen van wat er in de LTS zit aan te komen.
M.a.w. de non-LTS versies zijn gewoon soort beta versies? Milestone versies?

Wat is het verschil dan met de EA (Early Access) builds dan die Oracle en daarvoor Sun altijd al had?
Waaat? Weinig nieuws?

Het hele gebeuren rondom pattern-matching, wat zo met hapjes er in komt, is wat mij betreft DE beste verbetering in Java sinds de lambda/stream toevoeging.

Onze productiecode (veel netwerk-netwerk- en apparaat-protocollen) word zo veel leesbaarder met alle nieuwe mogelijkheden die switch krijgt, en we wachten met spanning op v25, zodat we onze product owner met het "LTS" kunnen knuppelen.
Het gaat hier specifiek over Java 23 en daar zitten nauwelijks nieuwe features in. Die pattern matching is ten opzichte van Java 22 iets uitgebreid, maar alleen als preview-feature.

Verder bevalt dat pattern matching mij ook prima, maar dat is een project dat jaren duurt en in deze versie geen grote sprong naar voren heeft gemaakt.
Voor protocol shizzle snap ik het wel. Voor een beetje crud schermen en webapps doet het niet zoveel.
Voor die doeleinden is Java best wel overkill vandaag de dag, je hebt zoveel meer lightweight opties waar je niet vast zit aan de nog steeds vrij logge Java runtime en garbage collector praktijken.

... maar Spring Boot Thymeleaf in combinatie met HTMX is wel echt een verademing, dat kan ik niet ontkennen.
Garbage collector is een verademing zeg ik als C/C++ programmeur ;-) En traag? Ach, na een paar tellen is de runtime "hot" en merk je daar niets meer van en met de juiste keuze in frameworks en moderne Java is het allemaal heel bruikbaar. In mijn ervaring beter dan de zoveelste versie ellende met de lightweight opties die volgende week niet meer compilen omdat iemand iets veranderd heeft.
Klopt :). Traag is inderdaad relatief. Is het trager dan heavy optimized C of C++? Tuurlijk, maar ook die kloof wordt bij elke release weer wat kleiner. Is het traag of zeg liever te traag voor pakweg 90% van je code, nee totaal niet.
Mee eens. Het gaat nog wel even duren voor we op het niveau van Scala (unapply) zitten, maar langzamerhand wordt het goed bruikbaar.
Zijn er überhaupt nog partijen die nu nog bewust voor Java kiezen? Met alle afpersingspraktijken van Oracle -niet alleen met Java- is het simpel voor ons: nooit (meer) Oracle. Simpelweg nooit. Leveranciers die een oplossing bieden met Oracle en/of Java komen er bij ons niet in.
Zijn er überhaupt nog partijen die nu nog bewust voor Java kiezen?
Zeker, ING, De Politie, De overheid, ASML en nog veel meer grote bedrijven.

Maar afpersingspraktijken? Alles is nu al een tijdje gewoon open, en er zijn meerdere partijen die JDK's aanleveren, hier https://sdkman.io/jdks kan je een makkelijk lijstje vinden van allerlei JDK vendors die je gratis en voor niet kan gebruiken, waaronder Amazon, Microsoft, Red Hat, SAP, IBM, Eclipse etc.

En ik verdien er ook genoeg geld mee als programmeur 8-)
Wat ik jammer vind is dat de meeste JDK vendors gebruik maken van OpenJDK. Maar of ze ook iets toevoegen (behalve een mooie installer schil) vraag ik me meer als eens af.
Krijg vaak een gratis Geld gevoel...
Die vendors leveren support tegen betaling. Daar heb je specialisten voor nodig (dus niet je gemiddelde Java developer) en die zijn niet bepaald gratis. Zonder support kan je hun JDKs doorgaans kosteloos gebruiken.

Verder zit er ook nog wel eens wat extra's bij. Azul had bijvoorbeeld een tijdje een erg fancy garbage collector. Corretto (Amazon) heeft er wat dingen in zitten die vooral op AWS fijn zijn om te hebben. Etcetera...
Ik heb het waarschijnlijk wat te kort door de bocht verwoordt. Dat ze modificaties doen voor eigenbelang is niet meer als logisch.
Ik bedoelde voornamelijk of er ook Geld etc terug gaat naar bv OpenJDK.
OpenJDK als entiteit zit niet direct op geld te wachten; dat is een beetje vreemde stelling. Maar dit soort grote partijen levert behalve bugfixes ook mankracht aan, om de ambitieuze projecten zoals Leyden te realiseren; een groot deel van de developers in dit project komt van Red Hat (IBM) en Amazon.
Toch is de vraag van @Motrax best valide. Ik zou wel eens willen weten waarom Adobe dit niet opgeslokt en uitgeperst heeft. Er zal vast een goede reden zijn, anders hadden ze het al gedaan. Zijn er soms voorwaarden aan de aankoop geweest o.i.d.?
Bedoel je Oracle ipv Adobe? Op dit vlak lijkt me doel 1 om te zorgen dat de programmeertaal op zoveel mogelijk plekken gebruik wordt. Daarna zoveel mogelijk support, cursussen en certificeringen te verkopen.
Er zijn anders voldoende JVMs die niet van Oracle zijn... Ik snap dat je geen Oracle wil, maar om daarmee Java buiten de deur te houden is wel erg kort door de bocht.
Tsja, Java is gelukkig breder dan Oracle. Ik ken niemand die de Oracle runtime vrijwillig gebruikt. Dat klopt. IBM zit er echter ook vuistdiep in en Azul ook bijv. Dus genoeg keuze. Een Android telefoon draait ook Java, zijn die ook verboden bij jullie? Helemaal Javaloos door het leven zie ik niet snel lukken, tenzij je de bakker om de hoek bedoelt.
Ik ben benieuwd wanneer er weer een LTS versie komt.
Oracle kennende kan dat nog wel even duren
Volgens Oracle zelf:

- versie 21 - sept. 2023 t/m 2028;
- versie 25 - sept. 2025 t/m 2030.
Dank voor de aanvulling.
Over een jaar dus
Oracle heeft juist een vrij goede en heldere release kadans. Elke twee jaar een LTS met vijf jaar support.
Oracle intends to make future LTS releases every two years meaning the next planned LTS release is Java 25 in September 2025.
Bron: https://www.oracle.com/nl...a-se-support-roadmap.html

Op dit item kan niet meer gereageerd worden.