Bulldogjob
Bulldogjob

Java 24 - wszystkie nowości

Java 24 została wydana. Sprawdzamy wszystkie 24 JEP-y, które trafiły do tej wersji.
18.03.20257 min
Java 24 - wszystkie nowości

Dziś premiera stabilnej wersji Javy 24. Jest to wydanie bez długoterminowego wsparcia, obowiązujące przez kolejne pół roku. Ogłoszenie Javy 25 zaplanowane jest na wrzesień 2025. Będzie to wydanie LTS (Long Term Support). Tymczasem przyglądamy się na świeżo wszystkim JEP-om JDK 24. Jest ich aż 24, co ładnie komponuje się z nowym numerem wersji.

Stream Gatherers

JEP 485 wprowadza operację Stream::gather(Gatherer), która pozwala na definiowanie niestandardowych operacji pośrednich na strumieniach - takich jak filtrowanie, okienkowanie, transformowanie. Ma to pomóc w zastąpieniu niezgrabnych collect() nową składnią. Ogólnie “zbieracze” zachowują stan i mogą działać równolegle. Java oferuje kilka wbudowanych implementacji (fold, mapConcurrent, scan, windowFixed, windowSliding), ale można pisać też swoje niestandardowe. Składnia w uproszczeniu wygląda tak:

source.gather(a).gather(b).gather(c).collect(...)

Jak widać gather to krok pośredni, a collect powinien być krokiem kończącym.

To jedyna stabilna zmiana w często używanych API w tym wydaniu.

Usprawnienia - głównie dla chmury

Java stara się być szybsza, zużywać mniej pamięci. Głównie dlatego, że twórcy Javy chcą, żeby królowała również w środowiskach chmurowych.

Kompaktowe nagłówki obiektów

Java 24 eksperymentuje ze zmniejszeniem nagłówków obiektów (JEP 450). Zmniejsza ona rozmiar nagłówka obiektu w HotSpot JVM z 96–128 bitów do 64 bitów na architekturach 64-bitowych (x64, AArch64). Niby niewiele, ale zespół Javy zauważył, że większość obiektów Javy jest mała, przez co same nagłówki zajmują nawet 20% całości. No cóż, oszczędzaj RAM, gdziekolwiek jesteś.

Zmiana jest na razie eksperymentalna, ale może znacząco wpłynąć na wydajność aplikacji w przyszłości.

AOT – Ładowanie i linkowanie klas przed uruchomieniem

JEP 483 wprowadza mechanizm AOT, który przyspiesza czas uruchamiania aplikacji w JVM poprzez wcześniejsze ładowanie i linkowanie klas. Zespół Javy zauważył, że większość aplikacji uruchamia się zwykle tak samo i postanowił to wykorzystać. Po przeprowadzeniu „treningowego” uruchomienia aplikacji, tworzony jest plik pamięci podręcznej AOT, który przyspiesza kolejne starty aplikacji.

Łączenie obrazów uruchomieniowych bez JMOD-ów

JEP 493 wprowadza możliwość tworzenia dostosowanych obrazów uruchomieniowych za pomocą narzędzia jlink, bez potrzeby używania plików JMOD. Dzięki temu rozmiar zainstalowanego JDK może zostać zmniejszony o około 25%. Funkcja ta musi być włączona podczas kompilacji JDK, ale nie jest domyślnie aktywna. 

Synchronizacja wątków wirtualnych bez przypinania do wątków systemowych

JEP 491 zmienia zachowanie wirtualnych wątków. Do tej pory gdy w kodzie została wykorzystana synchronizacja (synchronized) wątek musiał zostać przypięty do wątku systemowego. To rodziło problem, bo wątków systemowych jest mniej. Natomiast teraz wątki wirtualne będą się w takich sytuacjach dynamicznie montować i wymontowywać z wątków systemowych. Będzie to działać jak blokowanie operacji I/O.

Przydatne nowości, które są… prawie gotowe

W nowej wersji bardzo dużo JEP-ów jest w fazie preview, incubator lub experimental. Gdy nowość jest w preview, może się jeszcze nieco zmienić, ale ogólnie koncept pozostanie taki sam. Incubator rozwija stopnio ficzery i jest używany raczej do większych zmian, które wymagają wieloetapowego feedbacku. A experimental może w ogóle nigdy nie trafić do stabilnej wersji Javy, jeżeli nie spełni oczekiwań.

API funkcji pochodnej kluczy (Preview)

JEP 478 w Javie 24 wprowadza API dla funkcji pochodnej kluczy (KDF od Key Derivation Function), które umożliwia tworzenie dodatkowych kluczy na podstawie klucza tajnego i innych danych. 

Class-file API

JEP 484 wprowadza standardowe API do parsowania, generowania i transformowania plików klas w Javie. Celem jest ułatwienie przetwarzania plików klas zgodnie z definicją formatu JVM, eliminując zależności od zewnętrznych bibliotek jak ASM.

Scoped Values

JEP 487 wprowadza scoped values, które umożliwiają dzielenie się niemutowalnymi danymi pomiędzy metodami w tym samym wątku oraz z wątkami potomnymi. Scoped values są łatwiejsze do zrozumienia niż zmienne lokalne dla wątku, oferując lepszą wydajność i mniejsze koszty pamięci, szczególnie w połączeniu z wątkami wirtualnymi i współbieżnością strukturalną.

API było stopniowo rozwijane w JEP 429 (JDK 20), JEP 446 (JDK 21), JEP 464 (JDK 22) i JEP 481 (JDK 23). W JDK 24 wprowadzono poprawki, m.in. usunięcie metod callWhere i runWhere, co uprościło API. Funkcja nadal jest w preview, ale może zadebiutuje w Javie 25 jako stabilna?

Typy prymitywne we wzorcach, instanceof i switch 

Drugie preview tej funkcji (JEP 488). Dla przypomnienia: rozszerza to możliwości dopasowania wzorców w Javie, pozwalając na używanie typów prymitywnych w konstrukcjach instanceof i switch. Ma to rozwiązać problemy z bezpiecznym rzutowaniem typów. W obszarze dopasowania wzorców zawsze coś się dzieje i każde wydanie w ciągu ostatnich lat przynosiło jakieś poprawki do tego mechanizmu.

API wektorów

Nowe API do obsługi wektorów jest już 9 raz w inkubatorze (JEP 489). Jak już wcześniej ustaliliśmy zespół Javy przede wszystkim czeka tu na Project Valhalla, ale tym razem jest kilka nowości, natomiast nie są tak znaczące, żeby się o tym rozpisywać.

Elastyczne ciała konstruktorów 

JEP 492 wprowadza możliwość wykonywania instrukcji przed wywołaniem innego konstruktora (super(..) lub this(..)), co pozwala na inicjalizację pól instancji przed wywołaniem konstruktora nadrzędnego. Dzięki temu konstrukcja obiektów staje się bardziej elastyczna i niezawodna, zwłaszcza przy nadpisywaniu metod. Zmiana wprowadza podział ciała konstruktora na prolog i epilog, co upraszcza proces inicjalizacji obiektów. To zmiana preview.

Deklaracje importu modułów 

JEP 494 wprowadza możliwość importowania wszystkich pakietów eksportowanych przez moduł za pomocą jednej deklaracji import module, co upraszcza używanie bibliotek modularnych. Funkcja ta jest w fazie podglądu. Pozwala na łatwiejsze wykorzystanie API z wielu pakietów bez potrzeby ich manualnego importowania.

Proste pliki źródłowe i metody main instancji

4 raz w preview po to, żeby szybciej napisać “Hello World” w Javie (JEP 495). Serio ta zmiana jest po to, żeby móc napisać coś takiego:

void main() {
    println("Hello, World!");
}

Ustrukturyzowana współbieżność

JEP 499 to 4 preview dla funkcji Structured Concurrency. Znowu brak zmian, czeka na więcej feedbacku od społeczności. Pozwala na realizowanie jednego dużego zadania, jako wiele mniejszych kroków, realizowanych w oddzielnych wątkach. Całość traktowana jest jak jedna jednostka pracy, stąd nazwa “ustrukturyzowana współbieżność”.

Kryptografia odporna na kwanty

JEP 496 wprowadza do Javy implementację kwantowo-odpornego mechanizmu kapsułkowania kluczy ML-KEM, chroniącego przed atakami komputerów kwantowych. Bardzo podobna z nazwy jest inna nowość. JEP 497 wprowadza kwantowo-odporny algorytm podpisu cyfrowego ML-DSA.

Garbage collectory

Czym byłaby nowa wersja Javy 2X bez zmian w działaniu garbage collectorów? Pytanie retoryczne, ale wiadomo, to sytuacja nie do pomyślenia. Tym razem mamy 3 zmiany.

Nowy tryb Shenandoah GC

W Javie 24 wprowadzono eksperymentalny generacyjny tryb garbage collectora Shenandoah (JEP 404). Dzieli on pamięć na młodsze i starsze pokolenie, co pozwala na efektywniejsze zarządzanie pamięcią krótsze pauzy GC. Tryb włącza się za pomocą flagi -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational. Zmiana jest eksperymentalna, ale może przynieść korzyści w środowiskach chmurowych.

ZGC: Usunięcie trybu niegeneracyjnego

JEP 490 usuwa tryb niegeneracyjny ZGC, pozostawiając tylko generacyjny. Celem jest zmniejszenie kosztów utrzymania dwóch trybów. Po zmianach opcje związane z ZGenerational nie będą działa, a ZGC domyślnie przejdzie w tryb pokoleniowy. 

Opóźniona ekspansja barier dla G1

JEP 475 w Javie 24 optymalizuje obsługę barier G1 w kompilatorze C2, przesuwając ich ekspansję na późniejszy etap kompilacji. Zmiana ta redukuje narzut kompilatora nawet o 10-20%, upraszcza kod i eliminuje błędy wynikające z niewłaściwej kolejności operacji. Bariery będą rozwijane dopiero przy generowaniu kodu maszynowego, co zmniejsza obciążenie kompilatora, zachowując jakość wygenerowanego kodu.

Żegnamy się z

Pierwszy krok do ograniczenia JNI

W Javie 24 pojawią się ostrzeżenia dla programów korzystających z JNI (Java Native Interface) (JEP 472). To zapowiedź przyszłych zmian – w kolejnych wersjach Javy dostęp do JNI zostanie domyślnie ograniczony.

Nie jest to jakaś niespodzianka, bo dwie wersje temu pojawiło się w Javie Foreign Function & Memory API. Twórcy Javy sugerowali, że to będzie bezpieczniejszy i uwspółcześniony następca JNI. Na razie JNI nadal działa, ale warto zacząć myśleć o migracji.

Usunięcie portów 32-bit x86

JEP 479 w Javie 24 usuwa wsparcie dla portu Windows 32-bit x86, który został zdeprecjonowany w JDK 21. Natomiast JEP 501 oznacza port 32-bit dla Linuxa jako “do usunięcia”.

Ostrzeżenie przy użyciu metod dostępu do pamięci w sun.misc.Unsafe

JEP 498 wprowadza ostrzeżenie, które pojawi się przy wywołaniu metod dostępu do pamięci z klasy sun.misc.Unsafe, które zostały zdeprecjonowane w JDK 23. Zostały one zastąpione bezpiecznymi API, takimi jak VarHandle (JEP 193) i Foreign Function & Memory API (JEP 454). Celem jest ułatwienie migracji aplikacji do nowoczesnych, wspieranych rozwiązań.

Trwałe wyłączenie Security Managera

JEP 486 trwa usunięcie Security Managera, który przez lata był używany do zabezpieczania kodu w Javie. W wyniku jego małego znaczenia, zwłaszcza w kontekście aplikacji serwerowych, oraz kosztów utrzymania, został on zdeprecjonowany w Java 17 (JEP 411).

Podsumowanie

Niby to duże wydanie, bo aż 24 różne usprawnienia. Jednak stabilnych funkcji było niewiele. Oczywiście wpadło kilka usprawnień dedykowanych dla chmury czy garbage collectorów i stream gatherers, ale cała reszta to w zasadzie zapowiedzi przyszłych zmian. 

Prawdopodobnie wiele z nich zostanie włączone jako stabilne do Javy 25, czyli nowego LTS-a, który pojawi się już we wrześniu. Natomiast jest tego tyle, że mamy pewne wątpliwości, czy wyrobią się z tym wszystkim.

A Wy jak obstawiacie? Piszcie w komentarzach. Tymczasem zaczynamy odliczanie do września, do premiery Javy 25 w wydaniu LTS.

<p>Loading...</p>