JVM Tuesday vol. 85 - JDK 19, lżejszy CDI, nowy GraalVM i Kotlin

1. JDK 19 będzie gruube….

No dobra, JDK 19 sie rozpędza. W ostatnich tygodniach byliśmy wręcz zalewani nowościami. Teraz czas je zebrać i zagregować.

JEP 425: Virtual Threads (Preview)

Zacznijmy od informacji na którą wszyscy czekali – w JDK 19 zobaczymy wreszcie pierwszy preview oczekiwanego od lat Looma. Już tej jesieni będziemy mogli pobawić się wirtualnymi wątkami i bezboleśnie sprawdzić, czy całość wytrzymała cały hype z jakim wiązały się kolejne zapowiedzi projektu.

JEP 424: Foreign Function & Memory API (Preview)

Kolejny gracz wagi ultraciężkiej, czyli efekt Projektu Panama, również zobaczymy w najbliższym wydaniu JDK. Przed nami materializuje się następca JNI, który zapewnić ma nam nową, lepszą integrację z natywnym kodem. Nowe API jest naprawdę potężne i myślę że bliżej premiery (albo fazy Rampdown JDK 19) pochylimy się nad nim mocniej. Jeśli już teraz nie możecie się doczekać żeby poznać więcej szczegółów, polecam świeżutką prezentację od Oracle, która pokrywa w pełni JEP 424.

JEP 427: Pattern Matching for switch (Third Preview)

Tutaj ochy i achy trochę mniejsze, bo to już trzecia iteracja Pattern Matchingu dla javowych switchy. Zmiany wydają się być na plus – całkiem podoba mi się użycie słówka when dla operacji warunkowych (choć przyznam, że będzie mi się nieco gryzło z użyciem Kotlinowym). Czekam na switche bardzo i mam nadzieje, że to jest ostatnie preview i już niedługo doczekamy się wersji stabilnej. A jeśli chcecie więcej i nie lubicie formatu JEPów, polecam kolejne wideo-wprowadzenie od Oracle, prowadzone przez Venkata Subramaniana, częstego (i bardzo popularnego) gościa konferencji, również polskich.

To jednak nie wszystko, czego można się spodziewać po nowym wydaniu. JDK 19 to także przepięcie się Javy na nowy sposób renderowania aplikacji Desktopowych na komputerach z systemem macOS – OpenGL zostanie zastąpiony Metal API. Jest to inicjatywa, której efekty trafiły do Javy jeszcze w wersji 17 w ramach projektu Lanai, a od następnej wersji JDK zostaną w końcu włączone jako domyślne.

A jakbyście chcieli się pobawić, to najnowsze Early Access Buildy znajdziecie tutaj: http://jdk.java.net/19/

A wiecie co najbardziej mnie “jara”? Jest spora szansa, że choć część z powyższych Preview już niedługo stanie się stabilne wraz z następnym LTS (JDK 21). Już nie mogę się doczekać, jakie będą kolejne pomysły tych wszystkich utalentowanych inżynierów, którzy po latach pracy nad Loomem czy Panamą będą mogli zabrać się za coś nowego. Ciekawe jak będzie wyglądało JDK 29.

Jednym z takich nowych inicjatyw jest Projekt Liliput i dzieją się w nim ciekawe rzeczy, ale o nim porozmawiamy sobie może następnym razem.

2. CDI rozmnaża się przez pączkowanie

To porozmawialiśmy o zmianach, które afektują wszystkich, to teraz dla odmiany porozmawiajmy o tych, które dotkną pewnie sporo mniejszą część społeczności. Jesteśmy bowiem o krok od Jakarty EE 10, a poszczególne jej fragmenty już zostały zatwierdzone i “wmergowane” w specyfikacje. Między nimi znajduje się Jakarta Context Dependency Injection 4.0, która wprowadza pewne interesujące zmiany.

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ć ma wyłącznie najbardziej kluczowe aspekty CDI. Został zaprojektowany, żeby być w stanie wspierać potrzeby popularnych projektów, takich jak Dagger czy Guice, pomijając bardziej zaawansowane funkcjonalności powiązane z cyklem życia wstrzykiwanych zależności czy czy zarządzaniem nimi. 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.

I nie, to trochę jak z dietą – nowy, lżejszy CDI pomoże Wam nie kopnąć się w kolano, ale nie spodziewajcie się niesamowitych efektów wydajnościowych.

Całością można się już teraz pobawić, ponieważ zaraz po oficjalnym merge do sieci trafił Weld 5.0, czyli referencyjna specyfikacja standardu.

Źródła

3. Nowy GraalVM – szybciej, kompatybilniej… i z nową implementacją Stringa

No – doczekaliśmy się pierwszego w tym roku wydania GraalVM 2022.1, którego twórcy jak zwykle starają się zapewnić jak najlepszy Development Experience. Tym razem wzięli się za szybkość budowania Natywnych Obrazów. Quick build for Native Image, bo tak nazywa się jedna z wiodących funkcjonalności nowego wydania, służyć ma w sytuacjach, gdy nie zależy nam na maksymalnie zoptymalizowanym obrazie i wolimy zadowolić się czymś “wystarczająco dobrym” – na przykład podczas developmentu. Pokazane liczby wyglądają nienajgorzej, twórcy chwalą się bowiem średnio 43% szybszym generowaniem artefaktów:

Powyższe liczby byłyby nawet lepsze w przypadku porównywania z poprzednią wersją GraalVM, ponieważ (w stopniu drobniejszym, ale zawsze) przyspieszony został również standardowy build, a także zmniejszony rozmiar obrazów. Poniżej jak to wyglądało w poszczególnych wersjach:

Kolejną dużą nowością jest możliwość generowania natywnych obrazów dla procesorów M1. Nie podejrzewam, żeby ich produkcyjne użycie było czymś bardzo częstym, ale musimy pamiętać, że nowe Maci są jednak dość popularnym sprzętem dla programistów, więc ponownie – tryb developerski na pewno na tej zmianie zyska.

Usprawnień doczekały się również wsparcia GraalVM w ramach poszczególnych platform. Dzięki pracy programistów, Truffle w wersji dla Pythona, Reacta, JavaScripa, R czy Javy poszczycić się może zarówno lepszą kompatybilnością (również z konkretnymi systemami operacyjnymi), jak i wydajnością. Jest to zaskakujące, jak z każdą kolejną wersją twórcy projektu są coraz bliżej wizji uniwersalnej maszyny wirtualnej.

Na koniec zaś zmiana, która jest bardzo intrygująca – otóż do Truffle (baza dla wsparcia różnych języków w ramach GraalVM) wprowadzona została… własna implementacja Stringa. Ma być ona wydajniejsza i zapewniać wspólną abstrakcje dla wszystkich wspieranych przez Truffle językach. Podejrzewam, że realnie poliglotyczne środowiska rzeczywiście mogą na tym zyskać, ale nie mogę powiedzieć, żebym się trochę nie uśmiechnął na myśl o zaciąganiu zewnętrznej biblioteki na potrzeby tworzenia Stringów.

Ale może np. dla programistów JavaScript to coś zupełnie normalnego. Sam jeszcze pamiętam używania biblioteki, żeby wspierać BigInty w projekcie.

Bonus: Ziew… Kotlin 1.7 w Becie

A na koniec – Beta siódmej wersji Kotlina. A tak przy samej końcówce dlatego, że jest w niej raczej… mało ciekawego?

No bo jasne, dalsze usprawnienia wsparcia dla Builderów, przywrócenie “nienullowalnych” wariantów max() i min() czy nowe możliwości Regexpów to ciekawe rzeczy, ale jednak nie ma tego za wiele. Nawet najbardziej interesująca opcja wprowadzania statycznie sprawdzanych, nienullowalnych typów parametrycznych też chyba nie sprawia, że serduszka biją szybciej. Pozostałe funkcjonalności, jak nowa obsługa pamięci dla Kotlin Native, to już w ogóle bardzo niszowe featury.

Najciekawsza w tym kontekście jest sama zmiana terminologii. Zamiast kolejnych “Milestonów”, będziemy dostawać właśnie Bety. Beta oznacza de-facto feature freeze (aczkolwiek mogą pojawić się jeszcze zmiany wynikające z feedbacku użytkowników). Oznacza to, że poza powyżej opisanymi funkcjonalnościami raczej nic nowego w Kotlinie 1.7 nie zobaczymy. Jeśli JetBrains czymś nas nie zaskoczy w ostatniej chwili zapowiada się (kolejny już) mocno inkrementalny i nudny (zwłaszcza w kontekście zapowiedzi dla JDK 19) release.

JVM Tuesday vol. 85 – JDK 19, lżejszy CDI, nowy GraalVM i Kotlin