Wysyp nowych JEPów: Templating, kolekcje, Project Liliput i inne - JVM Weekly 108

1. Wysyp nowych JEPów – Spring Templating, kolekcje, Project Liliput i inne

Jesteśmy dość świeżo po premierze nowego JDK, dlatego też dość klasycznie wchodzimy w okres większego dynamizmu publikacji nowych JEP-ów. W ostatnich tygodniach pojawiło się parę ciekawych, którym teraz się przyglądniemy.

Niecały miesiąc temu opowiadałem o wymianach mailowych dotyczących projektu Amber, a już jesteśmy w stanie zobaczyć ich pierwsze efekty. Otóż zarówno nienazwane lokalne zmienne, jak i Pattern Matching dla Rekordów doczekały się swoich własnych JEP-ów w formie Draft. W porównaniu do wcześniejszych, nieco chaotycznych z perspektywy zewnętrznego czytelnika dyskusji mailingowych, zainteresowani są w stanie teraz zapoznać się z bardziej wykrystalizowaną, skondensowaną propozycją.

Kandydackich JEP-ów, który tym razem może zainteresować szeroką publikę jest JEP 431: Sequenced Collections. Jak sama nazwa wskazuje, jest to propozycja wspólnego interfejsu dla kolekcji zachowujących kolejność znajdujących się w nich elementów. Chęć wspólnej abstrakcji wynika z tego, że w tym momencie w zasadzie każda ze znajdujących się w JDK kolekcji zachowuje się w tej materii nieco inaczej. Nowy interfejs ma zapewnić ustandaryzowany sposób wybierania pierwszego i ostatniego elementu kolekcji.

void addFirst(E)
void addLast(E)
E getFirst()
E getLast()
E removeFirst()
E removeLast()

Rozbudowane mają być też interfejsy poszczególnych kolekcji, a każda z powyższych metod doczekać ma się defaultowej implementacji. Jest to więc kolejny przykład, jak wprowadzone jeszcze w JDK 8 mechanizmy ułatwiają ewolucję API biblioteki standardowej

Kocham fakt, że w summary całości znalazł się cytat z Kierkegaard

„Life can only be understood backwards; but it must be lived forwards.”

Stuart Marks, twórca JEP-a musi mieć zaciągi do filozofii 😉 A że też uwielbiam duńczyka, to też mi się zrobiło od razu chłodno na serduszku.

Kolejnym JEP-em, nad którym trwają obecnie intensywne prace jest JEP 430: String Templates (Preview). Zaskakujące jest, jak dość późno w swoim cyklu życia (język ma w końcu już trochę lat na karku) twórcy Javy zdecydowali się zabrać za ułatwienie programistom pracy z dłuższymi fragmentami tekstu, czyli na funkcjonalność istniejącą w zasadzie w chyba każdym innym języku JVM-owym. Po długich latach dopieszczania bloków tekstu, kolejnym krokiem jest ich udynamicznienie. Twórcy proponują następujący syntax:

String name = "Joan";
String info = STR."My name is \{name}";
assert info.equals("My name is Joan");   // true

W którym STR to tak zwany template processor, automatycznie importowany do każdego pliku Javowego .

Bardzo polecam lekturę oryginalnego JEP-a. W środku znajdziecie bowiem dość gruntowne porównanie syntax’u templatingu (i łączącej się z nim interpolacji) w innych języków, a także sensownie wyłożone argumenty za i przeciw poszczególnymi podejściami. Na szali położone zostają również rozwiązania już w JDK istniejące. Ogólnie całość jest dla mnie kolejnym przykładem tego, jak „oczywiste” na pierwszy rzut oka rozwiązania wcale nie są takie oczywiste. I to właśnie zwykle ta lekcja stanowi dla mnie o wartości lektury JEP-ów.

A na koniec – Project Liliput, o którym było cicho jakoś od maja i wczoraj rano wziął mnie z zaskoczenia nowym JEP-em: 64 bit object headers. celem Liliputa jest zmniejszenie rozmiaru nagłówków obiektów Java w maszynie JVM Hotspot ze 128 bitów do 64 bitów lub mniej. W tej chwili bowiem każdy obiekt, niezależnie czy mały, czy duży, posiada stały narzut w teorii 128-bitów, a w praktyce (przy włączonej kompresji nagłówków) 96-bitów. W ramach tej przestrzeni znajdują się wskaźniki do obiektu, jego hashcode, dane związane z Garbage Collectorami czy też lockami. 128-bitów nie wydaje się dużym narzutem pamięci, należy jednak pamiętać, że mówimy tutaj o nagłówku, który dokładany jest do każdego jednego obiektu. W wielu zastosowaniach np. Gdy tworzone jest wiele malutkich obiektów (twórcy powołują się np. na machinę learning), ten narzut staje się bardzo istotny, stąd prace nad Liliputem. Twórcom udało się w tej chwili uzyskać 64-bitowe nagłówki, kosztem zmniejszenia możliwego poziomu skomplikowania hashcodu i kilku innych optymalizacji. Wspomniany JEP zawiera szczegóły, które dokładnie fragmenty uległy redukcji i jakie implikacje zmiany mogą mieć dla przyszłego rozwoju min. Valhalli.

Bo grzebanie w internalach JVM to jednak trochę Jenga

Źródła

2. Spring eksperymentuje z Virtualnymi Wątkami, spóźni się z modułami.

W zeszłym tygodniu, w ramach konferencji JAX London, odbyła się sesja dotycząca zbliżającej się wielkimi krokami premiery nowego Springa Spring Boot 3 and Spring Framework 6 – a new generation. Niestety, nagranie nie jest dostępne w sieci, ale Infoq podzieliło się tym, co rzeczona sesja zawierała.

Także teraz ja, trochę głuchym telefonem, relacjonuje dalej.

Z pewnością dobrą wiadomością jest to, że dotrzymany ma być termin obu wydań, i nowych edycji możemy spodziewać się końcówką listopada, więc już całkiem niedługo. Nie będzie to jednak tak bogate wydanie, jak zapowiadało się przy pierwszych zapowiedziach – okazuje się bowiem, że długo oczekiwane wsparcie JPMSa, systemu modułów Javy, nie będzie gotowe na premierę. Jak przyznają twórcy, można się spodziewać jego pojawienia w późniejszych wersjach, ale pierwsza wersja Spring Framework 6 skupia się szczególnie na wsparciu kompilacji Ahead-of-Time i GraalVM, a moduły utrudniałyby ten proces, komplikując tak zwaną „analizę osiągalności”. Należy bowiem pamiętać, że w odróżnieniu od nowych graczy na rynku frameworków jak Quarkus, Helidon czy Micronaut, Spring bardzo, bardzo mocno opiera się na Reflection API. Dla niego więc proces wsparcia dla GraalVM, który refleksji nie wspiera jest więc znacznie trudniejszy.

Stąd też moduły zeszły na dalszy plan, twórcy jasno bowiem piszą, że liczą tutaj na Project Leyden, mający ustandaryzować tworzenie kompilacji AoT na JVM. Jako że jest to część JDK, musi brać JPMSa pod uwagę, co powinno sprawić, że praca programistów zewnętrznych w tym aspekcie będzie łatwiejsza. Na ten moment Spring wybiera jednak wsparcie Natywnych Obrazów.

Kolejną rzeczą, której twórcy Springa się przyglądają, jest rozwój wirtualnych wątków. We wtorek pojawiła się dość obszerna publikacja, która stanowi chyba pierwsze oficjalne stanowisko Springa w tej kwestii. Ponownie długie dziedzictwo frameworki kładzie się tutaj cieniem – framework posiada duże ilości bloków synchronized, co choć samo w sobie nie stanowi blokera, to jednak cały proces trochę komplikuje. Twórcy zdają sobie z tego jednak sprawę i analizują, którymi fragmentami muszą zająć się w pierwszej kolejności i eksperymentują z dostarczonymi przez JDK metodami. IMHO jako społeczność powinno nas to podejście cieszyć. Miło, że Springowi zależy na tym, aby realnie coś na tych wirtualnych wątkach zyskać, a nie tylko odhaczyć sobie kolejny „rewolucyjny” feature. Ponownie, nowi gracze mają łatwiej niż wieloletni gigant.

Ogólnie pokazuje to, że Annotation Procesory, na których bazuje Micronaut i koledzy, były dużym game-changerem dla przestrzeni frameworków. A nie ma chyba lepszego sposobu, żeby przekonać się jak dużym, niż się tym narzędziem pobawić i… zbudować własny framework. Zainteresowani? To mam dla Was na koniec coś naprawdę fajnego. Jacek Dubikowski rozpoczął w tym tygodniu serię Build your own framework using an annotation processor opisującą, nomen omen, proces tworzenia od zera własnego frameworku – takiego hobbystycznego, nie że zaraz wleci na produkcję (Java to nie JavaScript). Pierwszy artykuł dotyczy implementacji Dependency Injection i krok po kroku przeprowadza przez mechanizmy takiego procesu, a także potencjalne problemy mogące się pojawić po drodze. Polecam, zawsze uważałem, że reverse engineering i „tinkering” to najlepsze narzędzia edukacyjne.

Wysyp nowych JEPów: Templating, kolekcje, Project Liliput i inne – JVM Weekly 108

1. Wysyp nowych JEPów – Spring Templating, kolekcje, Project Liliput i inne

Źródła

2. Spring eksperymentuje z Virtualnymi Wątkami, spóźni się z modułami.

Źródła

Odkryj więcej świetnych treści!