Utgivelse av Java SE 26 og OpenJDK 26. Prosjektet for integrering av JavaScript- og Python-støtte i JVM.

Etter seks måneder med utvikling har Oracle publisert plattformen Java SE 26 (Java Platform, Standard Edition 26), der den åpne prosjektet OpenJDK brukes som referanseimplementering. Med unntak av fjerning av noen utdaterte funksjoner, er bakoverkompatibiliteten med tidligere versjoner av Java-plattformen bevart i Java SE 26 — de fleste tidligere utviklede Java-prosjektene vil fungere uten endringer under den nye versjonen. Klargjorte installasjonspakker for Java SE 26 (JDK, JRE og Server JRE) er tilgjengelig for Linux (x86_64, AArch64), Windows (x86_64) og macOS (x86_64, AArch64). Den standardiserte implementeringen av Java SE 26, utviklet under OpenJDK-prosjektet, er helt åpen under GPLv2-lisensen, med unntak for GNU ClassPath som tillater dynamisk sammenkobling med kommersielle produkter.

Java SE 26 er klassifisert som en utgave med vanlig supportsyklus, der oppdateringer vil bli utgitt frem til neste release. For langsiktig støtte (LTS) bør Java SE 25, Java SE 21 eller Java SE 17 brukes, med oppdateringer som vil bli utgitt frem til 2033, 2031, og 2029 henholdsvis (offentlig tilgjengelig — frem til september 2030, 2028 og 2026). Den utvidede støtten for LTS-grenen Java SE 8 vil vare frem til 2030, mens Java SE 11 vil vare frem til 2032.

Blant endringene i Java SE 26 (1, 2, 3, 4):

• Det er implementert en advarsel ved bruk av dyp refleksjon for å endre felt merket med nøkkelordet «final». I fremtiden er det planlagt å deaktivere usikre funksjoner i språket som standard og, blant annet, gjøre felt merket som final helt uforanderlige ved å fjerne muligheten til å endre dem via dyp refleksjon (API Reflection).
• API Applet (java.applet.Applet*, javax.swing.JApplet) er fjernet, som ble brukt til å kjøre Java-applikasjoner i nettleseren. Dette API-et mistet relevans etter at Java-plugin-støtten for nettlesere ble avsluttet og ble erklært utdaterte i 2021.
• Muligheten til å bruke forhåndsformet cache (AOT - ahead-of-time) er implementert med alle søppelsamlere, inkludert ZGC (Z Garbage Collector). Endringen innebærer støtte for sekvensiell lasting av bufrede Java-objekter i minnet, ved å bruke et universelt og søppelsamleruavhengig format i stedet for direkte mapping til minnet av spesifikke cache-representasjoner. Bruken av AOT-cachen reduserer oppstartstiden og akselererer oppvarmingen av HotSpot virtuelle maskinen.
• I HTTP Client API er det lagt til støtte for HTTP/3-protokollen, noe som lar applikasjoner og biblioteker kontakte servere via HTTP/3 etter minimale endringer i koden.
• Ytelsen til G1-søppeloppsamleren er forbedret ved å redusere blokkeringer for synkronisering av applikasjonstråder med søppeloppsamlertråder.
• Det er foreslått en annen forhåndsversjon av API for koding og avkoding av objekter med kryptografiske nøkler, sertifikater og lister over tilbakekalte sertifikater, ved å bruke PEM-formatet (Pivacy-Enhanced Mail).
• Det er foreslått for testing en sjette forhåndsversjon av API for strukturert parallellitet (Structured Concurrency), som forenkler utviklingen av flertrådede applikasjoner ved å behandle flere oppgaver som utføres i forskjellige tråder som en enkelt blokk.
• Den andre forhåndsredaksjonen av API Lazy Constants er lagt til for å jobbe med objekter som inneholder uforanderlige data og som behandles i JVM som konstanter. Optimaliseringer av ytelsen som ligner på felt med nøkkelordet «final» anvendes på slike objekter. I motsetning til «final» skiller det nye API-et skapelsen av faste verdier fra deres initialisering, garanterer at verdien kan initialiseres bare én gang, reduserer oppstartstiden for programmer og tillater brukerdefinerte optimaliseringer av konstantfolding (constant-folding), som tidligere bare ble brukt i indre JDK-kode. class Application { // Før: // static final UserService USERS = new UserService(); // Nå kan man: // static final StableValue<UserService> USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
• I mekanismen for mønster matching er den fjerde foreløpige varianten av muligheten til å bruke primitive typer (int, byte, char og andre grunnleggende typer som ikke er objekter) i alle typer maler, i "instanceof"-operatoren og i "switch"-blokker. switch (x.getStatus()) { case 0 -> "ok"; case 1 -> "advarsel"; case 2 -> "feil"; case int i -> "ukjent status: " + i; } if (i instanceof byte b) { … b … }
• Den ellevte testimplementeringen av API Vector er foreslått, som gir funksjoner for vektorberegninger som utføres ved hjelp av vektorinstruksjoner for prosessorer x86_64 og AArch64, og som gjør det mulig å bruke operasjoner samtidig på flere verdier (SIMD). I motsetning til funksjonaliteten for autovektorisering av skalaroperasjoner som tilbys i JIT-kompilatoren HotSpot, gir det nye API-et mulighet for eksplisitt kontroll over vektoriseringen for parallell databehandling.

I tillegg har Oracle annonsert prosjektet Detroit, som vil utvikles innenfor OpenJDK og har som mål å forbedre portabilitet mellom Java, JavaScript og Python. I rammen av prosjektet planlegger de å tilby muligheten for å integrere med JVM-runtime-prosessen med JavaScript-motoren V8 og CPython-tolkeren. Tidligere utviklet Oracle JavaScript-motoren Nashorn, som fungerte på toppen av JVM, men la ned prosjektet på grunn av vanskeligheter med å utvikle en separat implementering av JavaScript i en situasjon der hovedøkosystemet er basert på V8-motoren.

Det er også verdt å merke seg utgivelsen av oppdateringen for plattformen for å lage JavaFX-applikasjoner 26. I løpet av de nærmeste timene forventes også utgivelsen av den universelle virtuelle maskinen GraalVM 26, som støtter kjøring av applikasjoner på JavaScript (Node.js), Python, Ruby, R, nevn alle språk for JVM (Java, Scala, Clojure, Kotlin), samt språk som kan generere LLVM-byttekode (C, C++, Rust).

Kilde: opennet.ru