JDK 21 Strikes Again: Stabilne Wirtualne Wątki i Generacyjny ZGC – JVM Weekly vol. 128

1. JDK 21 Strikes Again: Stabilne Wirtualne Wątki i Generacyjny ZGC

Dopiero co tydzień temu poruszaliśmy temat tego, na jak ciekawe wydanie zapowiada się JDK 21, a już musimy do tematu wrócić, ponieważ grzechem byłoby poinformować o kolejnych potencjalnych nowościach, które do jesiennego LTS-a trafią. Otrzymaliśmy bowiem dwie kolejne duże zapowiedzi w tym temacie.

Zacznijmy od największej bomby, jaką jest pojawienie się draftu Wirtualnych Wątków w wersji stabilnej. Z jednej strony należało się spodziewać (drugi Preview był naprawdę kosmetyczny), z drugiej nie byłem pewien, czy jednak nie przyjdzie nam poczekać na stabilizację pozostałych feature projektu Loom i twórcy odpuszczą sobie jeszcze jesiennego LTS-a. Machina jednak ruszyła – ukazał się oficjalny JEP Draft, i to taki zawierający minimalną ilość zmian. Jedyną większą zmianą jest usunięcie możliwości wyłączenia wsparcia ThreadLocal. Jak pisze Ron Pressler, funkcjonalność była źle rozumiana i w planach twórców nigdy nie było całkowitego usunięcia ThreadLocala, jak mogłoby wynikać z takiej możliwości. Dla większej klarowności komunikacyjnej w koło wirtualnych wątków, ThreadLocal i Scope Locals zdecydowano się z tej możliwości po prostu zrezygnować.

I choć JEP na razie pozostaje Draftem, to jeśli tylko zostanie zaakceptowany, Virtual Threads wyjdą z Preview i zostaną stabilną funkcjonalnością w JDK 21. Teraz czekamy jeszcze na Structure Concurrency w preview i będzie można powiedzieć, że jesienna Java naprawdę

Drugi z nowych JEP-ów, tym razem zakwalifikowany jako kandydat do JDK 21, to JEP 439: Generational ZGC. Pewnie większość czytających te teksty słyszało czym jest hipoteza generacyjna, ale jako, że moja córka niedługo skończy dwa latka, to spróbuje potrenować wyjaśnienia ELI5 (Explain me like I’m Five).

Wyobraź sobie, że masz w swoim pokoju mnóstwo zabawek, z których część właśnie dostałeś, a część masz już od dawna. Możesz często bawić się nowymi zabawkami, ale w końcu znudzą ci się i przestaną sprawiać frajdę (to jest aż nazbyt prawdziwe…). Z drugiej strony, zabawkami które masz od dłuższego czasu może nie bawisz się aż tak często, ale skoro od roku Ci się to jeszcze nie znudziło, jest spora szansa że nie stanie się to jeszcze przez dłuższy czas.

Generacyjny garbage collector działa w ten sam sposób. Dzieli obiekty w pamięci na dwie grupy, młode obiekty i stare obiekty. Młode obiekty to te, które zostały dopiero co utworzone, a stare obiekty to te, które są już od jakiegoś czasu. Śmieciarka częściej sprawdza młode obiekty, ponieważ mają one tendencję do „umierania młodo”, czyli są tworzone, a następnie szybko stają się nieużywane. Stare obiekty są sprawdzane rzadziej, ponieważ jest bardziej prawdopodobne, że nadal są potrzebne. Dzieląc obiekty na generacje, garbage collector może zoptymalizować swoje zarządzanie pamięcią i zmniejszyć czas i zasoby potrzebne do zbierania śmieci.

Wyjątkiem jest tutaj właśnie ZGC – Garbage Collector, który służy do czyszczenia pamięci nawet o wielkości terabajtów bez przerwy dłuższej niż kilka milisekund. ZGC określany jest jako GC nisko-opóźnieniowe, które można uznać za swoisty state-of-the-art jeśli chodzi o maszynę wirtualną Javy. Nie jest to jednak rozwiązanie bez wad – design ZGC jest bardzo skomplikowany. Sprawiło to, że jego pierwsza (obecna) wersja jest jednogeneracyjna.

W związku z czym rozwiązanie zawsze miało problem z tak zwanym „oczyszczaniem młodej generacji”, czyli właśnie tych krótko żyjących obiektów. Twórcy od samego początku zapowiadali jednak, że nie poprzestaną na tym i teraz dostajemy w nasze ręce JEP 439: Generational ZGC. Co ciekawe, dotychczasowo nie zamierzano utrzymywać dwóch wersji ZGC – po implementacji wersji Generacyjnej oryginalna implementacji miała zniknąć. Okazało się jednak, że o ile nowy ZGC powinien być lepszym rozwiązaniem dla większości przypadków użycia niż nie-generacyjny ZGC, to ciągle istnieją przypadki, w których lepiej sprawdza się to drugie rozwiązanie. Dlatego też chwilowo twórcy zdecydowali się na utrzymanie obu ZGC, z założeniem pozbycia się oryginalnej wersji w przyszłości. Jest to bardzo nietuzinkowa sytuacja, w związku z czym ciekaw jestem JAK BARDZO zła jest wydajność generacyjnego ZGC w tych niektórych przypadkach, że twórcy zdecydowali się na utrzymaniu dwóch wariantów.

Jeśli chcecie dowiedzieć się więcej o samym ZGC, to w zależności od tego jaka forma najlepiej do Was trafia, polecam prezentacje wideo Java’s Highly Scalable Low-Latency Garbage Collector: ZGC lub podcast Towards Generational ZGC.

Źródła

• JEP 439: Generational ZGC
• JEP draft: Virtual Threads
• Java’s Highly Scalable Low-Latency Garbage Collector: ZGC
• Towards Generational ZGC.

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. Jak społeczność używa Jakarty EE?

We wrześniu 2022 roku OmniFish i OmniFaces przeprowadziły ankietę na temat Jakarta EE, zadając pytania związane z jej wykorzystaniem, serwerami aplikacji i API. W zeszłym tygodniu pojawiły się jego wyniki, zawierające kilka ciekawych obserwacji.

Zanim zacznę dzielić się danymi z ankiety, mały disclaimer – dane pochodzą z 720 odpowiedzi zebranych ze społeczności Jakarty EE. Mówimy więc o zbiorze z jednej strony stosunkowo małym, z drugiej jednak już statystycznie istotnym. Ze względu jednak na taką, a nie inną grupę badawczą (można założyć, że w badaniu wzięli udział Ci najbardziej zaangażowani użytkownicy Jakarty EE), dane mogą być zaburzone. Trzeba na nie spojrzeć więc z przymróżeniem oka i traktować raczej jako ciekawostkę, ale w dalszym ciągu mówiącą nam nieco o sentymencie ze strony społeczności.

Z danych wynika, że mimo walnego przechodzenia bibliotek i projektów na Jakarta EE 10, to wciąż Java EE 8 i Jakarta EE 8 są najczęściej używanymi wersjami. Trzeba jednak przyznać, że adopcja najnowszej Jakarty jest całkiem obiecująca – projekt ten zajmuje obecnie trzecią pozycję, wyprzedzając w ten sposób Jakarta EE 9.

Jeśli chodzi zaś o serwery aplikacyjne, to tutaj mamy do czynienia z wyścigiem łeb w łeb między WildFly a Payara Server. WildFly jest ciągle na czele stawki, ale Payara dość skutecznie zaskarbiła sobie serce społeczności. Oba projekty posiadają minimalny odsetek niezadowolonych/neutralnie nastawionych użytkowników, w obu przypadkach znacznie przeważają Ci którzy wypowiadają się o produktach w superlatywach

Po drugiej stronie stawki plasują się zaś WebSphere i WebLogic.

Mnie osobiście jednak najbardziej interesowały pytania o MicroProfile. Podobnie jak w innych latach, tylko mniejszość korzystała z API MicroProfile, ale odsetek, który korzysta z tych API, rośnie co roku. W 2018 roku było to 16%, w 2020 32%, a w 2022/2023 już 36% – widać więc wyraźny trend. Z ankiety wynika też, że koniem pociągowym jest Quarkus – to właśnie on jest deklarowany jako używany produkt przez ponad 50% użytkowników MicroProfile. Quarkus wyraźnie zagarnia więc pod siebie coraz więcej społeczności, a przepaść między nim, a drugim w rankingu WildFly jeszcze się powiększa. Ciekawa jest tutaj niska pozycja Helidona MP, który został wyprzedzony zarówno przez OpenLiberty, jak i Payara Server/Micro. Jak na to ile o samym projekcie się mówi to dość mocno widać, że traktowany jest on raczej jako eksperyment – przynajmniej przez społeczność Jakarty EE.

Z mojej perspektyw najciekawszym tematem związanym z MicroProfile jest jednak sentyment społeczności w kierunku łączenia projektu z Jakartą EE. Okazuje się, że użytkownicy nie mają tendencji separatystycznych i prawie 70% życzyła by sobie migracji obu projektów. Wróży to nienajgorzej na przyszłość, zwłaszcza biorąc pod uwagę adopcję przez MicroProfile 6.0 wprowadzonego w Jakarta EE 10 Core Profile, do czego doszło już po zebraniu wyników tego badania.

Na koniec jeszcze raz chce zauważyć, że badanie może być stronnicze w stronę bardziej aktywnych deweloperów OSS. Dlatego też OmniFish planuje następną wersję badania przeprowadzić we współpracy z Eclipse Foundation.

A jak już jesteśmy w temacie Jakarty EE, to biorąc pod uwagę że już w tym artykule mieliśmy kilka wideo, to podrzucę na koniec jeszcze bardzo ciekawe opracowanie historii wzajemnych relacji między Springiem, a Java EE. Całość pozwala lepiej zrozumieć zależności łączące obie platformy, i jak przez lata wpływały one na siebie. Całość powinna być interesująca dla wszystkich, którzy chcieliby poznać korzenie najważniejszych (chyba nie musimy bać się tego stwierdzenia) projektów ekosystemu Javy.

Źródła

• Jakarta EE Survey 2022/2023 – Results
• Has the J2EE vs Spring Infinity War reached an End Game? A short history of Java for the enterprise

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. Release Radar: Kotlin, Hilla

Kotlin 1.8.20-RC

Kotlin wydał wersję preview Kotlin 1.8.20-RC. Zwykle nie piszę o wersjach testowych, ale akurat Kotlin 1.x.20 to zawsze ciekawe wydanie, zasługujący na swoją wzmiankę, nawet jeszcze na poziomie RC.

Ciekawe zmiany pojawiły się też w kontekście kompilatora K2. Ten bowiem dostał wsparcie (na razie jako preview) pluginu do serializacji, pojawiła się też wersja Alpha kompilatora dla JS IR. Wreszcie, nowe podejście do kompilacji przyrostowej jest teraz dostępne domyślnie, co oznacza, że użytkownicy nie muszą już określać kotlin.incremental.useClasspathSnapshot=true w swoich gradle.properties, aby ją włączyć. W kontekście interoperacyjności z Javą, sam język dostanie eksperymentalne wsparcie dla interfejsu AutoCloseable. Doczekamy się też kodowania Base64 w bibliotece standardowej.

W wydaniu tym pojawia się też (na razie w wersji eksperymentalne) nowy „target” dla języka – Kotlin/Wasm. Nie jest to co prawda pierwszy raz, gdy możemy kompilować język do WebAssembly – do tej pory odbywało się to jednak przez Kotlin/Native. Nowe podejście (dzięki pominięciu LLVM w układance) ma zapewnić szybszą kompilację, a równocześnie lepszą interoperacyjność z JavaScriptem. Przy okazji, zespół Kotlina zdecydował się zrewidować listę platform wspieranych przez Kotlin/Native i zdeprecjonować niektóre z nich (min. Właśnie wasm32).

Vaadin Hilla 2.0

Mniej więcej rok temu Vaadin zaprezentował Hille – nowy framework webowy dla programistów Java, który umożliwia łatwe postawienie aplikacji “pełnostosowej” posiadającej backend oparty o Spring Boota i TypeScriptowy frontend. Znany wcześniej jako Vaadin Fusion, Hilla posiada kilka asów w rękawie, takich jak ujednolicona konfiguracja dla Java i TypeScripta. Projekt posiada też bogaty zestaw komponentów UI. Całość pozycjonuje się na konkurencje dla bardziej znanego JHipstera.

W zeszłym tygodniu pojawiła się wersja 2.0 projektu, która zawiera nowe funkcje, takie jak ulepszony generator TypeScript, wsparcie dla web socketów oraz GraalVM Native Image, uproszczone tworzenie theme oraz nowy SSO Kit, który umożliwia szybkie dodanie możliwości single sign-on do aplikacji Hilla. Nowe wydanie zbudowane jest w oparciu Spring Boot 3, Java 17 i Jakarta EE 10.

Na koniec warto wspomnieć, że twórcy już dzisiaj zapowiadają Hille 2.1, która ma zostać wydana w czerwcu 2023 roku i będzie zawierać lepszą obsługę formularzy, kolejne ulepszenia w SSO Kit oraz helpery do tworzenia aplikacji CRUD-owych. Umożliwiony ma być też deployment Hilli na funkcje AWS Lambda.