Po sześciu miesiącach prac rozwojowych firma Oracle opublikowała platformę Java SE 26 (Java Platform, Standard Edition 26), której referencyjna implementacja opiera się na otwartym projekcie OpenJDK. Z wyjątkiem usunięcia niektórych przestarzałych funkcji, w Java SE 26 zachowano zgodność wsteczną z wcześniejszymi wersjami platformy Java — większość wcześniej napisanych projektów Java będzie działać bez zmian w nowej wersji. Gotowe do zainstalowania wersje Java SE 26 (JDK, JRE i Server JRE) są dostępne dla systemów Linux (x86_64, AArch64), Windows (x86_64) oraz macOS (x86_64, AArch64). Referencyjna implementacja Java SE 26 opracowana w ramach projektu OpenJDK jest w pełni otwarta na licencji GPLv2 z wyjątkami GNU ClassPath, które zezwalają na dynamiczne wiązanie z komercyjnymi produktami.
Java SE 26 został zakwalifikowany jako wersja o standardowym okresie wsparcia, aktualizacje będą wydawane do następnej wersji. Jako wersję z długoterminowym wsparciem (LTS) należy używać Java SE 25, Java SE 21 lub Java SE 17, dla których aktualizacje będą wydawane do 2033, 2031 i 2029 roku odpowiednio (publiczne — do września 2030, 2028 i 2026 roku). Rozszerzone wsparcie dla gałęzi LTS Java SE 8 potrwa do 2030 roku, a Java SE 11 — do 2032 roku.
Wśród zmian w Java SE 26 (1, 2, 3, 4):
- Wprowadzono ostrzeżenie przy używaniu głębokiej refleksji do modyfikacji pól oznaczonych słowem kluczowym „final”. W przyszłości planowane jest domyślne wyłączenie niebezpiecznych możliwości języka, a także uczynienie pól oznaczonych jako final całkowicie niemutowalnymi poprzez wyeliminowanie obejścia pozwalającego na ich zmianę przez głęboką refleksję (API Reflection).
- Usunięto API Applet (java.applet.Applet*, javax.swing.JApplet), stosowane do uruchamiania aplikacji Java w przeglądarce. API to straciło na znaczeniu po zaprzestaniu wsparcia dla wtyczki Java w przeglądarkach i zostało uznane za przestarzałe w 2021 roku.
- Wprowadzono możliwość korzystania z wstępnie zbudowanej pamięci podręcznej (AOT — ahead-of-time) z dowolnymi zbieraczami śmieci, w tym ZGC (Z Garbage Collector). Zmiana ta oznacza wsparcie dla sekwencyjnego ładowania zbuforowanych obiektów Java do pamięci, wykorzystując uniwersalny format niezależny od zbieraczy śmieci, zamiast bezpośredniego mapowania na specyficzne reprezentacje pamięci podręcznej. Użycie pamięci podręcznej AOT skraca czas uruchamiania i przyspiesza warm-up maszyny wirtualnej HotSpot.
- W API HTTP Client dodano wsparcie dla protokołu HTTP/3, umożliwiając aplikacjom i bibliotekom łączenie się z serwerami za pomocą HTTP/3 po minimalnych zmianach w kodzie.
- Zwiększono wydajność zbieracza śmieci G1, dzięki redukcji blokad dla synchronizacji wątków aplikacji z wątkami zbieracza śmieci.
- Zaprezentowano drugą wstępną wersję API do kodowania i dekodowania obiektów z kluczami kryptograficznymi, certyfikatami oraz listami unieważnionych certyfikatów, wykorzystując format PEM (Pivacy-Enhanced Mail).
- Zaprezentowano do testów szóstą wstępną wersję API dla strukturalnego współbieżności (Structured Concurrency), która upraszcza rozwój aplikacji wielowątkowych poprzez traktowanie wielu zadań wykonywanych w różnych wątkach jako jednego bloku.
- Dodano drugą wstępną wersję API Lazy Constants do pracy z obiektami zawierającymi niezmienne dane, które są przetwarzane w JVM jako stałe. Do tych obiektów stosowane są optymalizacje wydajności, podobne do pól oznaczonych słowem kluczowym „final”. W przeciwieństwie do „final” nowe API oddziela tworzenie stałych wartości od ich inicjalizacji, zapewniając, że wartość może być zainicjowana tylko raz, skraca czas uruchamiania programów i pozwala na stosowanie w kodzie użytkownika optymalizacji zwijania stałych (constant-folding), które wcześniej były stosowane tylko w wewnętrznym kodzie JDK. class Application { // Było: // static final UserService USERS = new UserService(); // Teraz można: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
- W mechanizmie dopasowania do wzorca zaproponowano czwarty wstępny wariant możliwości wykorzystania typów prymitywnych (int, byte, char i inne podstawowe typy, które nie są obiektami) we wszystkich rodzajach szablonów, w operatorze „instanceof” oraz w blokach „switch”. switch (x.getStatus()) { case 0 -> „ok”; case 1 -> „ostrzeżenie”; case 2 -> „błąd”; case int i -> „nieznany status: ” + i; } if (i instanceof byte b) { … b … }
- Zaproponowano jedenastą testową implementację API Vector, oferującą funkcje do obliczeń wektorowych, które są realizowane z wykorzystaniem instrukcji wektorowych procesorów x86_64 i AArch64, pozwalającymi na jednoczesne zastosowanie operacji do wielu wartości (SIMD). W przeciwieństwie do możliwości automatycznej wektoryzacji operacji skalarnych oferowanych w kompilatorze JIT HotSpot, nowe API daje możliwość jawnego zarządzania wektoryzacją dla równoległego przetwarzania danych.
Dodatkowo, firma Oracle ogłosiła projekt Detroit, który będzie rozwijany w ramach OpenJDK i jest skierowany na poprawę przenośności pomiędzy Java, JavaScript i Python. W ramach projektu zamierzają udostępnić możliwość wbudowania w proces JVM runtime z silnikiem JavaScript V8 oraz interpreterem CPython. Wcześniej firma Oracle rozwijała silnik JavaScript Nashorn, działający na wirtualnej maszynie JVM, ale zakończyła projekt z powodu trudności z opracowaniem osobnej implementacji JavaScript w warunkach, gdy podstawowy ekosystem jest powiązany z silnikiem V8.
Dodatkowo można zauważyć publikację aktualizacji platformy do tworzenia aplikacji z graficznym interfejsem JavaFX 26. W najbliższych godzinach oczekiwany jest również wydanie uniwersalnej wirtualnej maszyny GraalVM 26, wspierającej uruchamianie aplikacji w JavaScript (Node.js), Pythonie, Rubym, R, dowolnych językach dla JVM (Java, Scala, Clojure, Kotlin) oraz w językach, dla których może być generowany kod bitowy LLVM (C, C++, Rust).
Źródło: opennet.ru
