Amber, Babylon, sun.misc.Unsafe i reszta: Plany na 2024 – JVM Weekly vol. 162

1. Plany Javy na 2024

Zacznijmy od video – Nicolai Parlog, Developer Advocate Javy, opublikował video z planami rozwoju języka na najbliższe dwanaście miesięcy:

TLDW: W 2024 roku Javę będzie rozwijać się przez projekty dobrze znane, jak Amber (dla mniejszych funkcji zwiększających produktywność) czy Valhalla (ulepszający model obiektowy Javy poprzez wartościowe obiekty dla lepszej wydajności), ale też nowe, jak Babylon (rozszerzający Javę o tak zwaną Code Reflection). Te projekty, a także znane już Leyden, Lilliput, Panama i Loom (który osiągnął większość celi i będzie stopniowo wygaszany), mają na celu ulepszenie Javy w obszarach takich jak refleksja kodu, czas uruchamiania, efektywność pamięciowa, kompatybilność z natywnym kodem czy współbieżność. Nie spodziewajcie się, że wszystkie działania zamkną się w bieżącym roku – wiele z powyższych zapewnię przeciągnie się na rok 2025.

Na który projekt czekacie najbardziej? Bo ja się bije z myślami, czy bardziej cieszę się na Leyden czy Babylon. Ten drugi ostatnio doczekał się też ciekawego epizodu airhacks.fm od Adama Biena, w którym w ponad godzinnej rozmowie Paul Sandoz odsłonił sporo detali stojących za Babylonem.

Dostaliśmy też pierwsze informacje w kontekście przyszłości Projektu Amber. Brian Goetz w klasycznej dla siebie formie mailo-eseju Towards member patterns przedstawia kompleksowy pogląd na przyszłą ewolucję pattern matchingu w Javie. W nim Goetz proponuje model mentalny dla dalszej integracji Pattern Matchingu w szerszym kontekście modelu obiektowego Java. Można sobie wyobrazić wzorce jako odwrotne konstruktory i metody, gdzie związek między wejściami a wyjściami jest odwrócony w porównaniu do tradycyjnych metod. Zasada dualności prowadzi do bardziej spójnego projektowania API, ponieważ zachęca programistów do myślenia o metodach i wzorcach jako o powiązanych parach.

Wraca więc prezentowany kiedyś konceptu „wzorców dekonstrukcyjnych”, które pozwalają każdej klasie zadeklarować wyraźny wzorzec do dekonstrukcji, stanowiąc uogólnienie nad istniejącym pattern matchingiem dla Rekordów. Tekst przedstawia przykładowo koncept wzorców statycznych, które mogą być używane dla klas preferujących statyczne fabryki nad konstruktorami. Widać, że Goetz myśli o Pattern Matchingu holistycznie i stara się obsłużyć jak najwięcej case. Tekst podkreśla jednak, że nie wszystkie mają odwrotności, ponieważ niektóre operacje, zwłaszcza te wiążące się z efektami ubocznymi lub skomplikowanym przeplatającym się argumentami, nie nadają się do takiej prostej inwersji.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Również początkiem roku – Nowe JEP-y

Pozostaniemy w tematach przyszłości Javy, ponieważ początek roku to też kilka nowych propsali. Oprócz kilku update’ów (które trochę później) mamy też absolutne nowinki, jak choćby

JEP draft: Deprecate Memory-Access Methods in sun.misc.Unsafe for Removal

No to wchodzimy w 2024 z przytupem, celem powyższego JEP-a jest bowiem deprekacja, a ostatecznie usunięcie metod umożliwiających dostęp do pamięci z klasy sun.misc.Unsafe, które powinny być internalowe dla JDK, ale przez lata była używana przez różne projekty, które chciały mieć bezpośrednią możliwość zarządzania pamięcią systemu operacyjnego (tak zwanej off-heap). Propozycja pojawia się w świetle bezpieczniejszych i bardziej wydajnych alternatyw: VarHandle w JDK 9 dla pamięci na stercie i MemorySegment w JDK 22 dla pamięci off-heap.

W pierwszej fazie wszystkie metody dostępu do pamięci w sun.misc.Unsafe zostaną oznaczone jako deprecated, produkując ostrzeżenia podczas kompilacji. W następnych krokach ich użycie będzie powodowało błędy kompilacji, z możliwością przekazania odpowiedniej flagi pozwalającą na ich wyłączenie. Następnie dojdzie do sekwencyjnego usuwania metod, najpier operujących na heap, a następnie tych off-heap. Proces będzie więc stopniowy, co pozwoli zminimalizować wpływ na istniejące biblioteki i aplikacje. Co ciekawe, JEP nie ma na celu usunięcia klasy sun.misc.Unsafe w całości, a konkretnych metod używanych do dostępu do pamięci – jednak w przyszłości planowane jest stopniowe pozbywanie się pozostałych operacji.

JEP draft: Implicitly Declared Classes and Instance Main Methods (Final)

Prace koncentrujące się na uczynieniu Javy bardziej dostępnym dla początkujących zbliżają się ku końcowi. Wygląda na to, że druga wersja preview, którą zobaczymy w JDK 22 jest rozwiązaniem ostatecznym. Wersja finalna nie wprowadza bowiem żadnych zmian, a tylko stabilizuje zaproponowane API.

JEP draft: String Templates (Final)

Dokładnie tak samo wygląda kwestia String Templates. Wszystko wskazuje na to, że te zostaną ustabilizowane w wersji zgodnej z tym, co zobaczymy przy okazji JDK 22.

JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

Powyższe to tylko drafty, ale doczekaliśmy się pierwszego JEPa targetowanego na wydanie JDK 23. Jest to też JEP szalenie ciekawy, ponieważ mowa o featurze, który jest strikte powiązany z Project Valhalla.

To po kolei, dla tych którzy gubią się już trochę w nowej terminologii. Project Valhalla wprowadza w Javie nową koncepcję znana jako „Primitive Types”, która ma na celu łączenie zalet typów prymitywnych – takich jak int czy double – z elastycznością obiektów. Głównym celem Primitive Types jest umożliwienie tworzenia typów danych, które działają z wydajnością typów prymitywnych, jednocześnie oferując możliwości obiektów, takie jak możliwość użycia jako typy generyczne i w kolekcjach. Ich cechy i charakterystyka ewoluowały wraz z kolejnymi iteracjami Valhalli, a teraz wreszcie dostaliśmy pierwszego związanego z nimi JEP-a, który został stargetowany na konkretne wydanie JDK.

JEP 455 koncentruje się na rozbudowie dopasowywania wzorców poprzez wprowadzenie Pattern Matchingu dla typów prymitywnych dla instrukcji instanceof i switch i ma na celu ujednolicenie traktowania wszystkich typów danych (zgodnie z wcześniej przedstawionym, maksymalistycznym podejściem Briana Goetza).

Ciekawe jest to, że całość została opublikowana jeszcze zanim dostaliśmy finalny proposal dotyczący samych typów prymitywnych. W praktyce oznacza to, że praca pewnie wrze i możemy niedługo spodziewać się nowych ogłoszeń. Całość mocno zaostrzyła mój apetyt na JDK 23 – oznacza bowiem, że jest to wydanie, które powinno zawierać znacznie więcej niespodzianek związanych z Valhallą.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Jakarta EE 11 jednak ze wsparciem dla JDK 17

Miałem wrażenie, że ostatni okres to ciągłe prześciganie się poszczególnych projektów o to, kto będzie wymagał najnowszej wersji Javy. Żeby nie szukać daleko, taki Spring Boot 3.0 czy nowe wydanie Quarkusa to minimalnie JDK 17, Helidon podbija stawkę, bo dla wersji 4.0 wymaga już JDK 21 – a podobnych ogłoszeń nie brakowało. Podobnie ambitne cele miało Eclipse Foundation, które to ogłaszało, że ze względu na wstępne wsparcie dla Wirtualnych Wątków w Jakarta Concurrency 3.1, od wydania Jakarta EE 11 programiści będą musieli używać właśnie JDK 21. Początek 2024 przyniósł jednak ogłoszenia o zmianach.

Ivar Grimstad, Developer Advocate Jakarta EE, poinformował bowiem o kroku wstecz – twórcy nowej wersji zdecydowali bowiem, że zmieniają decyzje i będą wspierać również JDK 17, a żeby otrzymać certyfikacje, implementacje standardu muszą spełniać specyfikacje zarówno na JDK 17, jak i 21. Decyzja ta wynika z obecnych trendów w zakresie adopcji technologii i preferencji użytkowników. Dane z New Relic i telemetrii VSCode Java wskazują na znaczące preferencje dla Java SE 17 lub niższych wersji, sugerując, że wymóg korzystania z Java SE 21 może być zbyt dużym ograniczeniem. Wsparcie zarówno dla Java SE 17, jak i 21 zapewnia, że migracja na Jakarta EE 11 będzie łatwiejsza. Zgodnie z dyskusją w GitHub Issue, wsparcie dla Wirtualnych Wątków ciągle pozostaje w zakresie wydania, po prostu w wypadku uruchomienia na JDK 17 API związane z Virtual Threads będą wykorzystywały klasyczne wątki. Jak to określa dokumentacja:

When {@code true}, the thread factory can create
* virtual threads if it is capable of doing so
* and if the request is not overridden by vendor-specific
* configuration that restricts the use of virtual threads.

Powiedzmy sobie szczerze – wsparcie dla JDK 17 ma sens. Jakarta EE nigdy nie była standardem, który wyznaczał trendy, a raczej stanowił pewną oazę stabilności, więc szersza kompatybilność w tym wypadku ma sens. Szkoda by było, żeby jedno jedyne API (Jakarta Concurrency 3.1) tak mocno utrudniało upgrade, zwłaszcza w organizacjach które mają bardzo ścisłe zasady dotyczące dopuszczonych wersji JDK. Ważne, żeby twórcy nie byli ograniczani przez kurczowe trzymanie się kompatybilności, ale kiedy i tak mowa była tylko o jednym API, jest to dla mnie zrozumiały kompromis.