Utgivning av Java SE 26 och OpenJDK 26. Projektet för att integrera stöd för JavaScript och Python i JVM

Efter sex månaders utveckling har Oracle publicerat plattformen Java SE 26 (Java Platform, Standard Edition 26), där den referensimplementation som används är det öppna projektet OpenJDK. Förutom att vissa föråldrade funktioner tagits bort, har Java SE 26 behållit bakåtkompatibiliteten med tidigare versioner av Java-plattformen — de flesta tidigare skrivna Java-projekten kommer att fungera utan ändringar på den nya versionen. De färdiga installationspaketen för Java SE 26 (JDK, JRE och Server JRE) är tillgängliga för Linux (x86_64, AArch64), Windows (x86_64) och macOS (x86_64, AArch64). Den referensimplementation av Java SE 26 som utvecklats inom ramen för projektet OpenJDK är helt öppen under GPLv2-licensen med undantag för GNU ClassPath, som möjliggör dynamisk länkning med kommersiella produkter.

Java SE 26 klassas som en version med vanlig supportcykel, där uppdateringar kommer att släppas fram till nästa release. För en version med långsiktig support (LTS) rekommenderas Java SE 25, Java SE 21 eller Java SE 17, vars uppdateringar kommer att släppas fram till 2033, 2031 respektive 2029 (offentliga uppdateringar — fram till september 2030, 2028 och 2026). Den utökade LTS-stöden för Java SE 8 kommer att pågå till 2030, medan Java SE 11 kommer att stödjas till 2032.

Bland förändringarna i Java SE 26 (1, 2, 3, 4):

• En varning har implementerats för användning av djup reflexion för att ändra fält märkta med nyckelordet "final". I framtiden planeras det att osäkra språkfunktioner som standard ska stängas av, och bland annat att fält märkta som final helt ska bli oföränderliga genom att eliminera genvägar för att förändra dem via djup reflexion (API Reflection).
• API Applet (java.applet.Applet*, javax.swing.JApplet) har tagits bort, vilket användes för att köra Java-applikationer i webbläsaren. Detta API blev omodernt efter att stödet för Java-plugin för webbläsare upphört och deklarerades föråldrat 2021.
• Möjligheten att använda förkompilerad cache (AOT - ahead-of-time) med alla skräparcollectorer, inklusive ZGC (Z Garbage Collector), har implementerats. Ändringen innebär stöd för sekventiell laddning av cachade Java-objekt i minnet, med en universell och skräparcollector-oberoende format istället för direkt mappning till minnet av specifika cache-representationer. Användningen av AOT-cache minskar starttiden och snabbar upp uppvärmningen av HotSpot virtuella maskinen.
• HTTP Client API:t har fått stöd för HTTP/3-protokollet, vilket gör det möjligt för applikationer och bibliotek att kommunicera med servrar via HTTP/3 efter minimala kodändringar.
• Prestandan hos G1-skräparcollectorn har förbättrats tack vare minskning av lås för att synkronisera applikationens trådar med skräparcollectorns trådar.
• Ett andra preliminärt API-förslag för kodning och avkodning av objekt med kryptografiska nycklar, certifikat och återkallade certifikat, med användning av PEM-formatet (Privacy-Enhanced Mail), har föreslagits.
• Ett sjätte preliminärt API-förslag för strukturerad parallellism (Structured Concurrency) har föreslagits för testning, vilket förenklar utvecklingen av flertrådiga applikationer genom att hantera flera uppgifter som körs i olika trådar som en enhetlig block.
• Den andra preliminära versionen av API för Lazy Constants har lagts till för att arbeta med objekt som innehåller oföränderliga data och som behandlas i JVM som konstanter. Likaså tillämpas prestandaoptimeringar för sådana objekt, liknande de för fält med nyckelordet 'final'. Till skillnad från 'final' separerar det nya API:t skapandet av permanenta värden och deras initiering, garanterar att värdet endast kan initieras en gång, minskar programstarttiden och möjliggör användning av optimeringar för konstantsvängning (constant-folding) i användarkoden, som tidigare endast användes i JDK:s interna kod. class Application { // Tidigare: // static final UserService USERS = new UserService(); // Nu kan man: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
• I mekanismen för mönstermatchning föreslås ett fjärde preliminärt alternativ för användning av primitiva typer (int, byte, char och andra grundläggande typer som inte är objekt) i alla typer av mallar, i operatören 'instanceof' och i 'switch'-block. switch (x.getStatus()) { case 0 -> 'okej'; case 1 -> 'varning'; case 2 -> 'fel'; case int i -> 'okänt status: ' + i; } if (i instanceof byte b) { … b … }
• Den elfte testimplementeringen av API:et Vector föreslås, vilket tillhandahåller funktioner för vektorberäkningar som utförs med hjälp av vektorinstruktioner från x86_64- och AArch64-processorer och tillåter samtidig tillämpning av operationer på flera värden (SIMD). Till skillnad från de funktioner som tillhandahålls av JIT-kompilatorn HotSpot för automatisk vektorisering av skalära operationer, ger det nya API:et möjlighet att uttryckligen styra vektoriseringen för parallell databehandling.

Dessutom har Oracle tillkännagett projektet Detroit, som kommer att utvecklas inom OpenJDK och syftar till att förbättra portabiliteten mellan Java, JavaScript och Python. Inom ramen för projektet avser man att möjliggöra inbäddning i JVM-runtime-processen med JavaScript-motorn V8 och CPython-tolkaren. Tidigare utvecklade Oracle JavaScript-motorn Nashorn, som kördes ovanpå JVM, men avbröts projektet på grund av svårigheterna att utveckla en separat JavaScript-implementation när den huvudsakliga ekosystemet är knutet till V8-motorn.

Det är också värt att notera publiceringen av en uppdatering av plattformen för att skapa applikationer med grafiskt gränssnitt JavaFX 26. Inom de närmaste timmarna förväntas också lanseringen av den universella virtuella maskinen GraalVM 26, som stöder körning av applikationer på JavaScript (Node.js), Python, Ruby, R, alla språk för JVM (Java, Scala, Clojure, Kotlin) och språk för vilka bitcode kan formuleras LLVM (C, C++, Rust).

Källa: opennet.ru