JVM Weekly #98 - Twórcy Vert.x zaczynają eksperymentować z Project Loom

1. Java 1.7 kończy żywot ☠️

I właśnie od tego ostatniego tematu zaczniemy. Dużo mówi się bowiem o powolnym umieraniu Javy 8, ale tak naprawdę gdzieś w jej cieniu pozostawała inna, przez lata bardzo popularna wersja. To właśnie na JDK 7 na lata zatrzymało się wiele projektów, i choć jej użycie powoli staje się raczej homeopatyczne (według różnych raportów zasila ona od jednego do pięciu procent aplikacji), to jednak w dalszym ciagu pozostaje sporo napisanego w niej kodu do migracji, który potrzebował po prostu hmmm… motywacji.

Czy raczej propozycji nie do odrzucenia.

Takowa właśnie po raz kolejny się pojawia, ponieważ w poprzedni weekend (31 lipca 2022) zakończył się okres Rozszerzonego Wsparcia dla Javy 7. Zgodnie z definicją Oracle Lifetime Support Policy, „Siódemka” przechodzi teraz w tryb Sustaining Support. Co to oznacza w praktyce? Nie będą dostarczane dalsze aktualizacje łatek, poprawki błędów i zabezpieczeń, ani implementacje funkcji… nie będzie niczego. Jedyne co daje Ci Sustaining Support to (bardzo drogie) zagwarantowanie, że jeśli nagle pojawi się jakiś olbrzymi problem z Twoją wersją Javy, to w zasadzie… masz do kogo zadzwonić. Oracle nie gwarantuje bowiem, że Twój problem rozwiąże – aczkolwiek historycznie duże firmy idą swoim wiernym, płacącym klientom na rękę. Taki np. Microsoft w czerwcu tego roku wydał pierwszy od 2017 nowy patch do Windowsa XP.

Źródła

2. GraalVM ułatwia pracę z zewnętrznymi bibliotekami

Porozmawialiśmy o przeszłości JVMa, czas spojrzeć w jego przyszłość. A żaden inny projekt nie oddaje takowej lepiej niż GraalVM, regularnie rozwijana alternatywna maszyna wirtualna dla Javy i nie tylko. Z regularnością zegarka szwajcarskiego wypluwane są jej nowe edycje, a w zeszłym tygodniu otrzymaliśmy kolejną. Co przynosi wersja 22.2?

Pierwszą dużą rzeczą jest modularyzacja. Do tej pory niezależnie od tego, który z wielu języków wspieranych przez GraalVM był przez nas używany (a w pewnie 90% przypadków jest to jednak Java), bazowy obraz zawierał pliki niezbędne do uruchomienia np. JavaScript czy LLVM, a także np. VisualVM. Z drugiej strony, taki Python czy Ruby musiały być już bezpośrednio doinstalowywane. Teraz sytuacja została posprzątana i każdy z dodatkowych modułów musi być doinstalowywany – „goły” GraalVM wspiera wyłącznie Javę. Zaletą tego rozwiązania jest to, że udało się mocno zredukować bazowy rozmiar obrazu, kosztem kilku dodatkowych komend dla programistów LLVM czy JS. Dla większego dobra.

Reakcja programistów JavaScript na zapowiedzi GraalVM

To oczywiście nie wszystko. Nowy GraalVM to też lepsza obsługa bibliotek zewnętrznych. Jako, że GraalVM tworzy statyczny obraz zawierający pre-kompilowane klasy, na etapie tworzenia artefaktu wynikowego zmuszony jest do wyczyszczenia tych klas, które nie są używane z poziomu wejścia aplikacji. O ile brzmi to rozsądnie, to w Javie dość mocno rozpanoszył się mechanizm refleksji, który sprawia, że aplikacja może odnieść się do arbitralnie dowolnej klasy dostępnej na classpath. A co jeśli takowego classpath nie ma? Szczęśliwie, możemy przekazać GraalVM listę klas, których nie powinien czyścić (programiści Androida znają ten mechanizm pewnie z ProGuarda). W wypadku bibliotek third-party prowadziło to jednak do duplikacji pracy, gdy każdy projekt musiał w zasadzie robić to samodzielnie. Dlatego wraz z nowym GraalVM pojawiło się GraalVM Reachability Metadata Repository, społecznościowe centrum pozwalające dzielić się takimi definicjami – trochę jak to mam miejsce z typami w TypeScripcie. Co najważniejsze – GraalVM Native Build Tools mogą zostać skonfigurowane, aby automatycznie zaciągać definicje do znalezionych w kodzie zależności.

Nowy GraalVM to również kilka innych nowości – możliwość łatwiejszego generowania ThreadDumpów, optymalizacje i poprawki wydajnościowe czy wsparcie Apple Silicon (bo od czasu wydania M2 ciężko już używać nazwy M1) w GraalVM Enterprise. Po więcej szczegółów zapraszam do lektury posta towarzyszącego nowemu wydaniu.

Źródła

GraalVM 22.2 Released

3. Twórcy Vert.x zaczynają eksperymentować z Project Loom

Projekt Loom coraz bardziej nam się panoszy. Parę edycji temu opisywaliśmy pierwsze eksperymenty twórców Quarkusa z tą technologią, koniec lipca przyniósł zaś ogłoszenie ze strony twórców Vert.x. Ten dość eksperymentalny projekt, który początkowo pozycjonował się jako alternatywa dla Node.js na JVM, aktualnie stanowi swoisty inkubator koncepcji związanych z reaktywnym i asynchronicznym programowaniem na JVM – dość powiedzieć, że np. taki Hibernate Reactive to właściwie nakładka nad stworzonymi w ramach Vert.x reaktywnymi sterownikami do baz danych.

Teraz framework bierze się za nowe zadanie – stworzenie referencyjnej wersji użycia wirtualnych wątków na potrzeby systemów reaktywnych. Loom to bowiem w zasadzie bardzo internalowa funkcjonalność – to co otrzymujemy wraz z projektem, to budulec dla twórców frameworków, których teraz zadaniem jest stworzyć abstrakcje, które będą dopiero używane przez „programistów przemysłowych”. I właśnie to zadanie bierze sobie Vert.x na plecy, ogłaszając Virtual threads incubator, projekt, który ma na celu dostarczeniu gotowych rozwiązań i wzorców. Na ten moment pierwszą, nie ostatnią z propozycji jest Vert.x Async/Await, ale już niedługo powinniśmy dostać kolejne. Osobiście zamierzam śledzić nowości w repozytorium vert-x3/vertx-virtual-threads-incubator i jak pojawią się kolejne ciekawe propozycje, na pewno trafią one do tego przeglądu.

Znając twórców Vert.x – oh, to będzie fun!

Źródła

4. Helidon 3.0 – Java 17, Jakarta EE i MicroProfile

No, a na koniec mamy dla Was nowe wydanie Helidona – edycję 3.0. Mimo, że framework pozostaje nieco w cieniu popularniejszych rozwiązań, takich jak Spring, Micronaut czy Quarkus, Helidon stanowi swoistą implementacje referencyjną dla MicroProfile i „mikro” Jakarty EE od samego Oracle. Dlatego przyglądniemy się, co przynosi nowa wersja.

I tutaj pierwsze zaskoczenie – otóż nowa edycja wymaga do działania minimum JDK 17. Oracle idzie jak burza.w procesie wypychania użytkowników na najnowsze LTS’y – jak widać na załączonym przykładzie, przyjęli metodę kija (minimalne wspierane wydania) i marchewki (istotne nowości).

Przy czym Java 17 to na dobrą sprawę też marchewka

Bo za takową „istotną nowość” z pewnością uznać można wsparcie dla MicroProfile 5.0 oraz wyselekcjonowanych aspektów Jakarta EE 9.1. W jakiś sposób zabawnym jest dla mnie, że wraz z tym podbiciem również framework od Oracle pozbywa się trademarkowanej paczki javax. na rzecz jakarta.. Twórcy chwalą się, że jest to pierwszy produkt korporacji który dokonał tej zmiany. Z funkcjonalności w Helidonie pojawił się również JEP 290: Filter Incoming Serialization Data, czyli usprawnienia bezpieczeństwa podczas procesu serializacji i deserializacji (takowa jest domyślnie w Helidonie 3.0 zresztą wyłączona), a także ulepszenia dla routing API.

Jednak nie tylko nowe możliwości samego frameworka są istotne, ale też to jak się go używa (o czym zapominają twórcy wspomnianego już Vert.x’a, mającego legendarnie fatalną dokumentację i release notes). Nowy Helidon przynosi też usprawnienia w kontekście Developer Experience. Wraz z nową wersją otrzymujemy bowiem nowy generator projektów – zarówno w wersji webowej, na modłę tego od Springa czy Jakarta EE pozwalający łatwo prekonfigurować bazę dla helidonowego projektu, jak i w formie CLI, dla tych preferujących terminal.