🥇Utgivelse av Java SE 24 og OpenJDK 24

Etter seks måneder med utvikling har Oracle lansert Java SE 24 (Java Platform, Standard Edition 24), hvor den åpne prosjektet OpenJDK benyttes som referanseimplementering. Bortsett fra fjerning av noen utdaterte funksjoner, opprettholder Java SE 24 bakoverkompatibilitet med tidligere versjoner av Java-plattformen — de fleste eksisterende Java-prosjekter vil fungere uten endringer når de kjører på den nye versjonen. Klargjorte installasjonsbygg for Java SE 24 (JDK, JRE og Server JRE) er tilgjengelige for Linux (x86_64, AArch64), Windows (x86_64) og macOS (x86_64, AArch64). Den referanseimplementeringen av Java SE 24 utviklet under prosjektet OpenJDK er helt åpen under GPLv2-lisensen med unntak for GNU ClassPath, som tillater dynamisk kobling med kommersielle produkter.

Java SE 24 er klassifisert som en utgivelse med vanlig støtte, med oppdateringer som vil bli utgitt frem til neste versjon. For langsiktig støtte (LTS) anbefales det å bruke Java SE 21 eller Java SE 17, hvor oppdateringer vil bli utgitt frem til henholdsvis 2031 og 2029 (offentlige oppdateringer frem til 2028 og 2026). Den utvidede støtten for LTS-grenen Java SE 8 vil vare til 2030, mens Java SE 11 vil ha støtte til 2032. Den neste LTS-utgivelsen blir høstutgivelsen Java SE 25.

Blant nyhetene i Java SE 24 finnes:

En eksperimentell generativ modus for søppelrytteren Shenandoah, som separerer håndteringen av gamle og nylig opprettede objekter for å forbedre effektiviteten i opprydningen av objekter med kort levetid. Den nye modusen gir mer forutsigbar båndbredde, robusthet mot lastvariabler og redusert minnebruk under søppelrydding. Shenandoah-planleggeren har som mål å redusere stoppetidene under søppelrydning gjennom å utføre mer arbeid parallelt med kjøringen av Java-applikasjoner.
I HotSpot JVM er eksperimentell støtte for kompakte objektoverskrifter implementert, hvor størrelsen på 64-bits systemer er redusert fra 96 til 64 biter (fra 12 til 8 byte). Reduksjonen av overskriftsstørrelsen bidrar til å redusere størrelsen på haugen og forbedrer cache-effektiviteten.
I søppelsamleren G1 er implementeringen av barrierer som sporer applikasjonens tilgang til minne forenklet. I den nye versjonen er operasjonen for utvidelse av barrierer flyttet til et senere stadium av kompilasjonen i C2 JIT. Utførte tester viser at en slik flytting kan redusere overheadet i C2 JIT-kompilatoren med 10-20% avhengig av applikasjonen.
Det er lagt til et API for bruk av kryptografiske funksjoner for nøkkelgenerering (KDF, key derivation function), som gjør det mulig å lage ekstra nøkler av ønsket lengde basert på en hemmelig nøkkel (for eksempel et passord) og en vilkårlig mengde data. KDF API har fortsatt status som foreløpig (preview).
Muligheten for forhåndslasting (Ahead-of-Time) og kompilering av klasser er lagt til. Endringen gjør det mulig å akselerere oppstarten av HotSpot JVM ved å levere klasser brukt i applikasjonen i allerede lastet og kompilert tilstand. Under første oppstart av applikasjonen blir tilstanden til alle klasser lagret i hurtigminnet, og ved påfølgende oppstarter brukes den for å akselerere lastingen.
Det er lagt til et API Class-File for analyse, generering og konvertering av filer med Java-klasser.
ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith(«debug»))) { classBuilder.with(ce); } } });
Det er lagt til et utvidet API Stream som støtter definisjon av egne mellomoperasjoner, som kan være nyttige i tilfeller der eksisterende innebygde mellomoperasjoner ikke er tilstrekkelige for ønsket datakonvertering. Egenbehandlere kobles til ved hjelp av den nye mellomoperasjonen Stream::gather(Gatherer), som behandler strømelementene ved å bruke den angitte brukerspesifikke behandleren. jshell> Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
Foreslått er den fjerde forhåndsimplementeringen av Scoped Values, som gjør det mulig å dele uforanderlige data i tråder og effektivt bytte data mellom undertråder (verdiene arves). Scoped Values utvikles for å erstatte mekanismen for tråd-lokale variabler og er mer effektive ved bruk av et stort antall virtuelle tråder (tusenvis og millioner av tråder). Den viktigste forskjellen mellom Scoped Values og tråd-lokale variabler er at de førstnevnte skrives én gang, kan ikke endres videre, og forblir tilgjengelige bare under kjøring av tråden.
For mekanismene for mønstergjenkjenning er det lagt til en forhåndsversjon av støtte for bruk av primitive typer (int, byte, char og andre grunnleggende typer som ikke er objekter) i alle former for maler, i 'instanceof'-operatoren og i 'switch'-blokker. switch (x.getStatus()) { case 0 -> "okay"; case 1 -> "warning"; case 2 -> "error"; case int i -> "unknown status: " + i; } if (i instanceof byte b) { … b … }
Den niende forhåndsimplementeringen av API Vector er foreslått, som tilbyr funksjoner for vektorberegninger som utføres med vektorinnstruksjoner fra x86_64- og AArch64-prosessorer, og som lar deg anvende operasjoner samtidig på flere verdier (SIMD). I motsetning til mulighetene for autovektorisering av skalaroperasjoner som tilbys av JIT-kompilatoren HotSpot, gir det nye API-et muligheten til å styre vektoriseringen eksplisitt for parallell databehandling.
Støtte for synkronisering av virtuelle tråder uten at de festes (pinning) til plattformrelaterte tråder er implementert. Virtuelle tråder i en synkronisert metode eller uttrykk i en blokkering frigir nå sin plattformtråd, slik at andre virtuelle tråder kan bruke den, noe som betydelig øker antallet tilgjengelige virtuelle tråder og forbedrer skalerbarheten til applikasjoner som bruker multitråding.
Det er lagt til en tredje foreløpig variant av muligheten som tillater angivelse i uttrykkbyggerne før anropet av super(…), brukt for å eksplisitt kalle konstruktøren til foreldreklassen fra konstruktøren til den arvede klassen, hvis disse uttrykkene ikke refererer til instansen laget av konstruktøren. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
I verktøyet jlink er det implementert støtte for å opprette kjørbare bilder uten bruk av JMOD-filer, noe som kan redusere størrelsen på JDK med omtrent 25%.
Det er lagt til en andre foreløpig variant av bruk av uttrykket «import module M» for å importere alle pakkene som eksponeres av den angitte modulen. Denne endringen forenkler vesentlig gjenbruk av modulbiblioteker, ettersom det tillater tilknytning av biblioteker og klasser uten å spesifisere deres plassering i pakkemodellens hierarki. For eksempel vil «import module java.base» importere alle 54 pakkene som inngår i java.base-modulen, som tidligere måtte nevnes hver for seg («import java.io.*», «import java.util.*» osv.).
Den fjerde foreløpige implementeringen av implicit erklærte klasser og anonyme instanser av metoden «main» er lagt til, der man kan unngå offentlige/static-erklæringer, overføring av argumentarrayer og andre elementer knyttet til klasseerklæring. // før public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // nå kan man void main() { System.out.println("Hello, World!"); }
Det er foreslått for testing en fjerde foreløpig variant av API for strukturert parallellisme (Structured Concurrency), som forenkler utviklingen av flertrådede applikasjoner ved å behandle flere oppgaver som utføres i forskjellige tråder som en enkelt blokk.
I API-ene KeyPairGenerator, Signature og KeyFactory er det lagt til støtte for algoritmene ML-KEM (CRYSTALS-Kyber) og ML-DSA (CRYSTALS-Dilithium), standardisert av National Institute of Standards and Technology (NIST) og motstandsdyktig mot kryptoangrep på kvantedatamaskiner. Disse algoritmene bruker kryptografiske metoder basert på løsningen av oppgaver innen gitterteori, der løsningstiden ikke er forskjellig på vanlige og kvantedatamaskiner.
I søppelsamleren ZGC er støtte for ikke-generativ driftsmodus fjernet, som ikke skiller mellom behandling av «gamle» og «unge» objekter. Fra og med Java SE 23 er generativ modus for ZGC aktivert som standard.
Det er lagt til varsler om bruk av API JNI (Java Native Interface) og FFM (Foreign Function & Memory) for å forberede utviklere på begrensningene i tilgangen til disse APIene, som vil bli innført i en av de fremtidige utgivelsene med en modus for integritetsbeskyttelse som som standard forbyr interaksjon med native kode.
Varsling er aktivert ved bruk av metoder for tilgang til ekstern minne (utenfor JVM) som tilbys av klassen sun.misc.Unsafe. For tilgang til minne utenfor haugen (off-heap) og interaksjon med ekstern kode anbefales det å bruke VarHandle API. Støtten for sun.misc.Unsafe ble erklært foreldet i forrige utgave.
Security Manager er deaktivert, ettersom det lenge har vært utdatert og ikke vært etterspurt etter at støtten for nettleserpluginen ble opphevet. Security Manager ble erklært foreldet i Java 17. I en av de kommende utgivelsene planlegges det å fjerne Security Manager-koden helt.
Koden for støtte av 32-biters Windows-plattform på x86-systemer er fjernet. Java-porten for 32-biters x86-systemer er erklært foreldet og planlagt for fjerning (støtten for Linux på 32-biters x86-systemer vil bli opphevet).

I tillegg kan vi nevne utgivelsen av plattformoppdateringen for JavaFX 24 og den nye utgivelsen av GraalVM, som støtter kjøring av applikasjoner skrevet i JavaScript (Node.js), Python, Ruby, R, samt alle språk for JVM (Java, Scala, Clojure, Kotlin) og språk der det kan genereres LLVM-bitkode (C, C++, Rust). I tillegg til støtten for JDK 24 har den nye versjonen av GraalVM optimaliseringer for maskinlæringsoppgaver, forbedret støtte for kompilering av Java-bytekode til maskinkode, samt et SkipFlow-mekanisme for å redusere størrelsen på de kjørbare filene og forkorte kompileringstiden.

Kilde: opennet.ru