Przyszłość i teraźniejszość Java Enterprise: pierwsze spojrzenie na Jakarta EE 11 i adopcja MicroProfile 6 - JVM Weekly vol. 133

1. Wysyp nowych kandydackich JEP-ów

Zacznijmy od największej kobyły – JEP 447: Statements before super(). Ten JEP jest ciekawy, ponieważ zawiera zmiany w JLS – Java Language Specification. Jest to formalny dokument, który opisuje składnię i semantykę Javy. JLS jest przewodnikiem nie tyle dla programistów, co twórców kompilatorów i narzędzi w celu zapewnienia spójnej i dokładnej implementacji języka na różnych platformach i środowiskach.

Nie każdy JEP zawiera zmiany w specyfikacji języka. Przykładami JEPów edytujących JLS są np. JEP 286: Local-Variable Type Inference (nowe słowo kluczowe 'var’ jego reguły) czy też JEP 354: Switch Expressions, rozszerzający instrukcję switch, aby mogła być używana również jako wyrażenie, a także wprowadzający użycie tak zwanych „Arrow labels” (np. case 1 ->). JLS musiał zostać zaktualizowany, aby pomieścić wspomnianą nową składnię switch.

Wracając do JEP 447: Statements before super(), proposal ma na celu rozluźnienie ograniczeń dotyczących Javowych konstruktorów i umożliwić na inne wywołania jeszcze przed this() lub super(), o ile pola instancji nie są odczytywane do czasu zakończenia konstrukcji superklasy, takich jak np. inicjalizowania zmiennych.

Co ciekawe, Java Virtual Machine Specification (JVMS) – czyli odpowiednik JLS dla maszyny wirtualnej – już na to pozwala. To JLS ma pewne ograniczenia związane z kontekstem statycznym (i pewnymi bugami z przeszłości), ale z punktu widzenia VM nie są one konieczne do prawidłowego funkcjonowania konstruktorów. Proponowane zmiany stworzyłyby nową koncepcję zwaną „kontekstem pre-inicjalizacji”, która jest mniej restrykcyjna niż istniejący „kontekst statyczny” i pozwoliłaby na pojawienie się deklaracji przed wywołaniami this() i super().

Ostatnimi tygodniami pojawił się również JEP 449: Deprecate the Windows x86-32 Port. Poprzez niego, twórcy Javy przymierzają się do usunięcia wersji JDK na system operacyjny Windows w wersji 32-bitowej. Na taki krok złożyło się kilka czynników, jak choćby fakt, że Microsoft (zmiana została zaproponowana zresztą przez tą właśnie firmę) ostatecznie przestał już wydawać nowe wersje 32-bitowych systemów operacyjnych, a ostatni z nich (Windows 10) straci wsparcie twórców w drugiej połowie 2025. Znacznie ciekawsze są jednak tutaj pobudki praktyczne – z JEP-a okazuje się bowiem, że implementacja Wirtualny Wątków nie jest kompatybilna z 32-bitowymi procesorami.

Pewnie powyższe było wiadome od dawna, a tylko dla mnie to wzięło z zaskoczenia i dowiedziałem się o tym dopiero na poziomie draftu powyższego JEP-a.

Także już niedługo chcących zbudować aplikację przy pomocy JDK na porzuconych systemach, przywita Was poniższy komunikat.

configure: error: The Windows x86-32 port is deprecated and may be removed in a future release.

No cóż, procesory 32-bitowe odchodzą już w niepamięć – ostatnią wspieraną wersją pozostanie ta na architekturę arm32.

Można się rozejść za to jeśli chodzi o JEP 446, Scoped Values (Preview).

Poniższy fragment (szary) to jedyne zmiany jakie pojawiły się między JEP 446 – Scoped Values (Preview), a JEP 429: Scoped Values (Incubator), który pojawił się w JDK 20. Jak widzicie, za wiele tego nie ma.

A, i tym razem nie zapomnieli o Vector API, jak to miało miejsce przy JDK 20. W JEP 448 dostało swoją (już szóstą) inkubację. Ale to w zasadzie jedyna ciekawa informacja w kontekście tego API, od dawna już czekającego na premierę Valhalla API. Długoterminowym celem Vector API jest bowiem wykorzystanie ulepszeń Valhalli, zwłaszcza Value Classes, nie posiadających tożsamości. Vector API będzie więc inkubowane przez wiele wydań, aż niezbędne funkcje Projektu Valhalla staną się dostępne jako Preview. Wtedy Vector API zostanie dostosowane do jego semantyki i również dopiero wtedy trafi do Preview.

Źródła

2. Pierwsze informacje na temat Jakarta EE 11

Ostatni tydzień to również wysyp informacji dotyczących szeroko rozumianej Enterprise Java. Zacznijmy więc od pierwszego dużego ogłoszenia, którym jest prezentacja pierwszych założeń wobec Jakarty EE 11.

Komitet sterujący Jakarta EE nakreślił cztery główne obszary priorytetowe dla projektów: ułatwienie „wejścia” w projekt nowym członkom społeczności, ujednolicenie platformy wokół nowoczesnych API takich jak CDI oraz ograniczenie wewnętrznych niespójności, które nawarstwiły się przez lata, wprowadzenie nowych specyfikacji, takich jak Jakarta Config czy Jakarta Data, a „dogonienie” nowoczesnej Javy.. Nowe wydanie ma na celu wykorzystanie nowości, jakie pojawią się w najnowszym LTS – Java 21. Wprawdzie twórcy nie deklarują na tym etapie chęci porzucenia starszych wydań, ale w zapowiedzi przewija się np. użycie nowych możliwości jakie daje Project Loom. Twórcy nie zapominają jednak o kilku ostatnich latach rozwoju platformy i deklarują chęć bliższego przyglądnięcia się również nowością z kilku ostatnich lat, jak np. Rekordom.

Bardzo ciekawie wygląda aspekt społecznościowy. Proces angażowania się w rozwój platformy musi być uproszczony, z wyraźniejszymi drogowskazami i wskazówkami dla nowych współpracowników – standaryzacja procedur w różnych projektach i lepsza dokumentacja ma pomóc to osiągnąć. Pierwszą jaskółką może być fakt, że już na tak wczesnym etapie twórcy udostępnili dokument (w Google Docsach!), pozwalający przyglądnąć się w szczegółach pomysłom przyświecającym nowemu wydaniu. Można przykładowo, zobaczyć od kuchni jak wyglądają takie tematy jak zbliżanie do siebie MicroProfile i Jakarty, czy stopniowe odchodzenie od EJB.

Docelowa data wydania Jakarta EE 11 to pierwszy kwartał 2024 roku, około sześć miesięcy po wydaniu Java 21.

To jednak nie koniec nowości związanych z szeroko rozumianą Enterprise Java, ponieważ wydany został WildFly 28. Projekt ten ostatnio porzucił Release Train, przechodząc na wydania związane z jakimiś konkretnymi, dużymi nowymi funkcjonalnościami. Tym razem jest to dopasowanie się do ostatnich zmian w MicroProfile.

Szczególnie duże zmiany zaszły w kontekście tak zwanej „obserwowalności”, ale żeby je zrozumieć, trzeba nakreślić nieco szerszego kontekstu. Organizacją zajmującą się tworzeniem standardów jeśli chodzi o Tracing – czyli śledzenia poszczególnych zdarzeń w ramach aplikacji – jest Cloud Native Computing Foundation (w skrócie CNCF). Przez lata rozwijane było kilka konkurencyjnych projektów, takich jak OpenCensus czy OpenTracing. Ten ostatni trafił do MicroProfile jako MicroProfile OpenTracing API, implementacji tegoż zaś posiadał WildFly.

CNCF początkiem roku zdecydował się na porzucenie rozwoju OpenTracingu na rzecz OpenTelemetry, będącego nieco szerszym projektem, przez co MicroProfile OpenTracing API oberwało rykoszetem i od wersji 6.0 projektu również przestało być wspierane. Na jego miejsce powstało MicroProfile Telemetry Tracing, implementujące standard Tracingu pochodzący OpenTelemetry. W związku z tym, WildFly również dokonał u siebie takich zmian, tworząc nowy moduł microprofile-telemetry, który zastąpi OpenTelemtry.

To jednak nie koniec – WildFly postanowił porzucić wsparcie dla MicroProfile Metrics API, standardu metryk rozwijanego w ramach MicroProfile. Zamiast tego WildFly używać będzie Micrometer, podobnej w swojej naturze do SLF4J fasady umożliwiającej pracę z wieloma systemami metryk. Kluczowym dla podjęcia takiej decyzji jest stabilizacja OpenTelemetry Metrics – czyli komplementarnego dla OpenTelemetry Tracing standardu metryk – który przez Micrometer jest wspierany. Są to kroki, które poczynił ostatnio również Quarkus – Micrometer staje się więc powoli standardem jeśli chodzi o Javowe Metryki.

Ale jak to jest z tymi standardami to my dobrze wiemy

Kończąc temat MicroProfile, WildFly wprowadza wsparcie dla MicroProfile LRA (Long Running Action), stanowiącego poboczny projekt, nie wchodzący w skład głównego standardu. Nowy WildFly posiada też trochę pomniejszych zmian, ale te już polecam wam sprawdzić samemu w Release Notes.

Kończąc tą i tak przydługą serie, warto wspomnieć o nowym wydaniu Open Liberty, „chmuronatywnego” serwera aplikacyjnego rozwijanego przez IBM. Nowe wydanie OpenLiberty 23.0.0 to duży skok do przodu – zawiera pełne wsparcie dla Jakarta EE 10, funkcjonalności przychodzące z JDK 20 oraz MicroProfile 6. Zwłaszcza ten ostatni jest tutaj interesujący – w odróżnieniu od WildFly, IBM zdecydował się również na wsparcie MP Metrics.

Dzięki temu mogą się chwalić pełną kompatybilnością ze standardem MicroProfile 6.0 – wybór Micrometer jako dostawcy metryk sprawił, że WildFly nie może sobie na to pozwolić.

Źródła

3. Release Radar: Micronaut & Ktor

Micronaut 3.9.0

Micronaut wydał Micronaut Framework 3.9.0, wprowadzając nowe funkcje, takie jak konfigurowalne pakiety introspekcji z adnotacją @Introspected, konfigurację CORS opartą na adnotacjach. Wydanie zawiera również masę aktualizacji poszczególnych modułów – „dużej” nowej wersji (4.0) doczekał się Micronaut Kubernetes, a aktualizacji Micronaut Security, Micronaut Maven, Micronaut Launch/CLI, a także Micronaut CRaC. Z tym ostatnim wiąże się fakt, że od nowego wydania funkcje AWS Lambda utworzone za pomocą Micronaut mają domyślnie włączony AWS SnapStart.

Micronaut Framework rozszerzył też wsparcie rodzajów plików konfiguracyjnych, i wspiera teraz YAML, properties, TOML, Groovy i Hocon. Poza samym wsparciem, dokumentacja projektu została zaktualizowana, aby pokazać fragmenty konfiguracji w różnych obsługiwanych formatach.

Wysypu mniejszych i większych aktualizacji doczekały się też integracje zewnętrzne. Micronaut 3.9.0 przynosi kilka nowych – do Azure Cosmos DB, Google CloudEvents, Google Cloud Functions czy Slacka. Wiele już istniejących, jak min. Micronaut ElasticSearch czy Micronaut Micrometer, doczekało się zaś aktualizacji.

Ktor 2.3.0

Żeby tak nie było, że nowe wydanie jest tak zupełnie pozbawione wątków Kotlinowych – JetBrains wydało Ktor 2.3.0, wprowadzającego wiele małych usprawnień. Między innymi, Sockety dostały wsparcie lepsze wsparcie Korutyn oraz Structure Concurrency, WebSocket otrzymały zaś wsparcie typowania. Idąc też za rozwojem samego Kotlina, nowe wydanie pozywa się istniejącego kompilatora JavaScript, używając nowej warstwy pośredniej.

Dodatkowo, routing dostał wsparcie wyrażeń regularnych, doszło do refactoru Static Content API, pojawiło się też wsparcie dla Jetty 11 i Tomcat 10 Udostępniono też możliwość scalania kilku plików konfiguracyjnych, co ułatwia modularyzację projektów. Kończąc listę zmian, sanityzacja wrażliwych nagłówków jest teraz dostępna w pluginie Logging.

PS: Pojawił się też Quarkus 3.0. Ale jest to na tyle duże wydanie, że chce się nim najpierw trochę pobawić i poświęcić całą osobną sekcje. Zmian pod sodem jest tam bowiem cała masa.

Przyszłość i teraźniejszość Java Enterprise: pierwsze spojrzenie na Jakarta EE 11 i adopcja MicroProfile 6 – JVM Weekly vol. 133

1. Wysyp nowych kandydackich JEP-ów

Źródła

2. Pierwsze informacje na temat Jakarta EE 11

Źródła

3. Release Radar: Micronaut & Ktor

Micronaut 3.9.0

Ktor 2.3.0

Odkryj więcej świetnych treści!