Czy Jakarta EE zawalczy z Microprofile o serca tworzących mikroserwisy? - JVM Weekly #106

1. Czy Jakarta EE zawalczy z Microprofile o serca tworzących mikroserwisy?

Sezonowość wiadomości w świecie JVM jest niesamowita (albo i nie-tak-niesamowita, bo prawdopodobnie skorelowana z okresem wakacyjnym). Albo w społeczności nie dzieje się nic (jak potrafiło być w niektóre lipcowe/sierpniowe tygodnie), albo co tydzień dostajemy wysyp nowości – taki był cały wrzesień. Otóż w zeszłą środę cała edycja poświęcona była premierze świeżusieńkiej JDK 19, a dziś mamy dla Was Jakartę EE 10, będącą zwieńczenie ostatnich dwóch lat prac. Ostatnie większe wydanie (Jakarta EE 9.1) skupiało się na dopinaniu zmian związanych z przejściem na zupełnie nowy namespace, „dziesiątka” przynosi szereg dużych aktualizacji.

Jeżeli miałbym wskazać jedną, największą zmianę w nowym wydaniu, wybrałbym chyba pojawienie się nowego Profilu – Core. Czym są profile? Kiedyś mieliśmy tylko jeden wariant Java EE, co było proste, ale powodowało problemy. Standard był szeroki, a aby przejść certyfikacje dany serwer aplikacyjny musiał zaimplementować każde nowe API, co wydłużało czas adopcji nowych rozwiązań. Dlatego też twórcy JEE wyróżnili dwa profile – Full i Web, gdzie ten drugi przeznaczony był dla typowych aplikacji Webowych.

To wszystko jednak działo się w epoce, zanim zaczęliśmy pakować nasze aplikacje w pojedyncze deployowane jarki. Ta zmiana – oraz nowa generacja rozwiązań – spowodowała konieczność dalszego dokrojenia liczby kluczowych API wyłącznie do tych przydatnych w takim use-case. Tak powstał niezależny od Jakarty EE MicroProfile, a teraz jego konkurent(?) – oficjalny profil Core Jakarty EE. Dlaczego Jakarta EE tworzy własne rozwiązanie zamiast dogadać się z Microprofile? TLDR: Związane jest to z elastycznością, której twórcy MP łakną, a której Jakarta EE nie jest za bardzo w stanie im zaoferować. Nie oznacza to jednak, że między projektami jest jakikolwiek konflikt – w tej chwili jednak Core Profile będzie mógł po prostu stanowić bazę, którą MicroProfile będzie w stanie rozbudowywać.

Przejdźmy teraz do nowości w samych API. Zacznijmy od Jakarta Context and Dependency Injection (CDI) 4.0. Od lat trwa proces nieustannego odchudzania korporacyjnej Javy, i w tym kierunku zmierzył też popularny CDI. Jego struktura w ogóle zrobiła się mocno skomplikowana. Oprócz podziału na wersje SE (dla standardowej Javy, używana min. przez Helidon) i EE, teraz pojawiły się kolejne warianty – CDI Full oraz CDI Lite. Ten ostatni zawiera wyłącznie najbardziej kluczowe aspekty CDI. Został zaprojektowany w celu wsparcia potrzeby popularnych bibliotek, takich jak Dagger czy Guice, pomijając bardziej zaawansowane funkcjonalności powiązane z cyklem życia wstrzykiwanych zależności. Podejrzewam, że dla większości z naszych czytelników CDI Lite będzie docelowym rozwiązaniem – to właśnie on będzie używany przez popularne frameworki jak Quarkus czy Micronaut. Jeżeli jesteście ciekawi szerszego opracowania, bardzo dobre znajdziecie na The Server Side.

Użytkownicy CDI ucieszą się również z kolejnej interesującej zmiany, jaką przynosi Jakarta Concurrency 3.0. Otóż wprowadza ona kompatybilną z CDI 4.0 wersję adnotacji @Asynchronous, do tej pory współpracującej wyłącznie z EJB. Wynikiem metod oznaczonych za pomocą @Asynchronous musi być ComputableFuture, a dodatkowo mamy możliwość sprecyzowania thread poola, na którym odbywać mają się wykonania. Stanowi to krok do przodu w stosunku do wariantu starych Enterprise Java Beans, który wymuszał użycie puli zdefiniowanej przez serwer aplikacyjny.

Schodząc trochę z tematu zarządzania zależnościami – Jakarta Security w wersji 3.0 przynosi długo oczekiwane wsparcie OpenID Connect, co z pewnością ucieszy twórców aplikacji używających zewnętrznych dostawców tożsamości do autoryzacji użytkowników. Jakarta RESTful Web Services 3.1 to zaś Java SE Bootstrap API – czyli możliwość używania serwisów Restowych np. w testach. Po latach też doczekaliśmy się też oficjalnego wsparcia UUID jako typu danych w Jakarta Persistent API, jak teraz rozwija się powszechnie znany skrót JPA.

Całość dopełnia aktualizacja Jakarta Faces, których czwarta wersja ukazuje się w ramach JEE 10. Największą zmianą jest ucieczka od EJB w stronę wspomnianego już CDI. Ułatwione ma być też tworzenie widoków HTML-owych bezpośrednio z kodu javowego – powstało do tego dedykowane API. Czy to wystarczy, aby odzyskać serce społeczności, która wyraźnie straciła serce do projektu? Ostatnio w sieci pojawiło się kilka pozytywnych opinii na temat drogi, którą przeszedł projekt, ale z mojej perspektywy raczej nawet powrót mody na Server-Side Rendering nie wystarczy, abyśmy zaobserwowali masową adopcję.

Jakarta Faces od początku pozycjonowała się jako rozwiązanie, które pozwala programistom Java tworzyć aplikacje full-stackowe, nawet bez biegłości w JavaScripcie. Dlatego na koniec sekcji Jakartowej nie mógłbym nie wspomnieć o apelu, który Ryan Dahl – twórca Node.js – wystosował w kierunku Oracle. Okazuje się, że ze względu na zawiłości historyczne i prawne, to właśnie Oracle posiada prawa do nazwy (trademark) JavaScript, co jest bardzo nie w smak społeczności projektu. Wskazywane są dokładnie te same ryzyka, które zmusiły społeczność do długoletniej migracji z brandu Java EE na Jakarta EE. Wskazywane jest, że kiedyś Oracle może postanowić swojego trademarku bronić, a już dzisiaj nazwa jest czymś mocno toksycznym dla wielu podmiotów, bojących się nadepnąć korporacji Larry’ego Ellisona.

Źródła

2. JDK 19 – alternatywne dystrybucje, bezpieczeństwo i Garbage Collectory

Tydzień temu mieliśmy do czynienia z premierą nowego JDK, co oznacza, że nie mogło zabrakło wielu stałych „wydarzeń towarzyszących”.

Zacznijmy od tego, że bardzo szybko zaczęły się pojawiać warianty oficjalnego JDK. Corretto (JDK od Amazona) w wersji 19 jest już dostępne na AWS-ie, a także do pobrania do użytku lokalnego. O publikacji swojej edycji nowego JDK poinformowało również BellSoft, którego Liberica JDK również została zaktualizowana. Tutaj ciekawostką jest fakt, że o ile wersja ciągle dostępna jest na stronie Downloads, to jednak z jakiegoś powodu post zapowiadający gdzieś zniknął w chwili pisania tego tekstu… czyżby premiera okazała się falstartem? Jeżeli jesteście użytkownikami Liberici, sugeruje jeszcze chwilę wstrzymać się z aktualizacją.

Jeżeli jesteście skonfundowani różnicami pomiędzy poszczególnymi JDK, polecam lekturę strony whichjdk.com, która pozwoli Wam odnaleźć się w gąszczu różnorakich wariantów JDK.

Prawdopodobnie jednak większości programistów będzie trochę bez różnicy czy ich aplikacja uruchomiona będzie przy pomocy OpenJDK, Liberica JDK, Correto czy też może Azul. Nie tak zupełnie bez różnicy może okazać się jednak zmiany w samym JDK, o których nie pisaliśmy ani my w poprzedniej edycji, ani większość publikacji pokrywających temat JDK 19. Poza samymi JEP-ami każde wydanie Javy przynosi bowiem też sporo poprawek pod maską, często w dziedzinach takich jak bezpieczeństwo czy wydajność. Na szczęście te mocniej wyspecjalizowane aspekty platformy posiadają swoich czempionów. Pierwszym z nich jest Sean Mullan, który niestrudzenie co pół roku publikuje każdorazowo przegląd tego, co w danej edycji JDK zmieniło się w takich aspektach jak właśnie security, kryptografia i cała związana z nimi narzędziówka. I tak w „dziewiętnastce” mowa jest min. zwiększeniu długości (a więc też zwiększeniu trudności potencjalnego ataku) kluczy dla podstawowych algorytmów szyfrowania czy zwiększeniu wydajności TLS. Nie brakuje również pewnych poprawek w toolingu, a wisienką na torcie jest przesunięcie kilku algorytmów, w tym wciąż popularnego MD5, do kategorii algorytmów Legacy.

Tak, MD5 absolutnie nie powinno już być popularne.

Na sam koniec zaś Thomas Schatzl i jego przegląd nowości w Garbage Collectorach. Okres, gdy kolejne wydania JDK wręcz prześcigały się o to, które upcha więcej JEPów w tej kategorii, jest już chyba za nami (przynajmniej na jakiś czas), ale nie oznacza to, że absolutnie nic się w tej materii ciekawego nie wyłożyło. W końcu gwiazdą nowego wydania Javy były wirtualne wątki, o charakterystykach wydajnościowych mocno odbiegających od współbieżności, do której użytkownicy JVM byli przyzwyczajeni. Okazuje się bowiem, że włączenie Looma (który, przypominam, jest w wersji testowej) powoduje znaczne skomplikowanie procesu odśmiecania i potrzebę przyspieszenia deprekacji tak zwanego sweepera. Ogólnie mniejszych i większych poprawek jest około dwustu, a ich listę znajdziecie w oficjalnym trackerze JDK. Post Thomasa przynosi też trochę perspektyw na przyszłość – w JDK 20 możemy się spodziewać dużej refaktoryzacji G1, o której początkiem sierpnia napisałem nawet pastę, a autor notatkę na swoim blogu.

Źródła

3. Oficjalna Roadmapa GraalVM opublikowana

A na koniec, roadmapa! I to nie byle jaka, bo swoimi planami na przyszłość postanowił podzielić się ze społecznością GraalVM. Co dowiedzieliśmy się z zaprezentowanej przez twórców planów na najbliższy czas?

Także jak ktoś nie lubię spoilerów, to sugerujemy zakończyć lekturę dzisiejszej edycji. Resztę zapraszam!

Roadmapa została podzielona na dwie kategorie – zmiany w natywnych obrazach (i ich kompilatorze) oraz samym środowisku uruchomieniowym projektu. Całość jest też bardzo przyjemna w konsumpcji, ponieważ wykorzystuje natywne githubowe funkcjonalności zarządzania projektami (jest to jeden z pierwszych projektów, w których to widzę).

Ale forma formą, treść się liczy. Roadmapa pozwala podglądnąć, czego można spodziewać się od nowego dużego wydania GraalVM, które już 25 października. Jeżeli chodzi o runtime, zakończone zostało wsparcie dla LLVM na Windowsie i node.js dla M1. Pojawią się również poprawki dla Pythona i Ruby’ego. Tym wszystkim jednak zajmiemy się bliżej przy oficjalnej premierze.

Jeszcze ciekawsze rzeczy znajdziemy znajdziemy jednak w zakładce dotyczące kompilatora. Okazało się bowiem, że GraalVM dostanie pełne wsparcie wirtualnych wątków, które pojawiły się w niedawno wydanej JDK 19. Co ciekawe, okazuje się, że oryginalne wsparcie sztandarowej inicjatywy Project Loom pojawiło się już chwile temu, ale w samym JDK twórcy poczynili trochę zmian, do których GraalVM musiał się dopasować. Drugim bardzo ciekawym aspektem jest zaś początek pracy nad oficjalnym API dla wszystkich zewnętrznych narzędzi, które chcą wzbogacić tooling GraalVM. Do tej pory musieli grzebać w internalach, co jest ryzykowne dla długoterminowych planów projektu.

Nikt nie chce skończyć się nowym `sun.misc.Unsafe`.

Całość roadmapy wychodzi jednak poza bieżące wydanie. Dowiemy się z niej więc o planach lepszego wsparcia ZGC, JFR, AWT i innych typowo javowych technologii. Pojawić się ma też mechanizm pozwala na częściową inicjalizację aplikacji w czasie tworzenia obrazu czy też otwarcie źródeł Ideal Graph Visualizer – narzędzia deweloperskiego pozwalającego użytkownikom analizować wykresy kompilacji i badać problemy z wydajnością. Ten do tej pory dostępny był tylko w wydaniach Enterprise, teraz ma trafić też do Community Edition. Oczywiście, jest tego znacznie więcej, ale to już będziemy pewnie informować, gdy plany zaczną się krystalizować. Ciekawe czasy przed GraalVM.

A jak już w temacie Virtual Threadów – nowy odcinek Inside Java Newscast zawiera przegląd narzędzi, które uzyskały wsparcie dla Wirtualnych Wątków. Bardzo polecam obejrzeć – po krótkim wprowadzeniu do samego Looma, od około czwartej minuty zaczyna się prawdziwe mięsko. Jest tego nawet więcej niż się spodziewałem, a myślałem, że śledzę temat dość uważnie – także polecam.

Czy Jakarta EE zawalczy z Microprofile o serca tworzących mikroserwisy? – JVM Weekly #106

1. Czy Jakarta EE zawalczy z Microprofile o serca tworzących mikroserwisy?

Źródła

2. JDK 19 – alternatywne dystrybucje, bezpieczeństwo i Garbage Collectory

Źródła

3. Oficjalna Roadmapa GraalVM opublikowana

Źródła

Odkryj więcej świetnych treści!