JVM Tuesday vol.56 – Java 17... again. A także Refleksja w czasie kompilacji 🤯

1. Java 17 – najciekawsze ogłoszenia od Oracle 🧝‍♀️

Zanim przejdziemy do głosu społeczności, skupmy się na zapowiedziach od samego Oracle – mamy bowiem do czynienia aż z trzema dużymi. Zmianą, która w największym stopniu wpłynie na życie programistów, będzie z pewnością zwiększenie częstotliwości wydań LTS (Long-Time Support). Do tej pory ukazywały się one co trzy lata – aktualnie okres ten zostanie skrócony do dwóch. Ma to uzasadnienie w badaniach przeprowadzonych przez Oracle. Mimo, iż wersje pośrednie mają swoich amatorów, to jednak większość dużych firm zdecydowała się na używanie wydań z długim wsparciem. Skrócenie okresu między wersjami jest więc ukłonem w stronę społeczności i pozwoli na częstsze dostarczanie nowych funkcji, w mniejszych “paczkach”. Dzięki temu, każda aktualizacja powinna być też łatwiejsza.

Jednak to nie koniec zmian ze strony Oracle. Firma zaskoczyła wszystkich ponownie kombinując z licencją JDK – postanowili dystrybuować Oracle JDK (czyli swoją edycję Javy – nie mylić z Oracle OpenJDK), przy użyciu licencji o wdzięcznej nazwie „Oracle No-Fee Terms and Conditions”. Ma ona zezwalać na bezpłatne korzystanie z produktu wszystkim użytkownikom, nawet do użytku komercyjnego i produkcyjnego. Nie pozwala jednak na redystrybucje za opłatą – czyli prawdopodobnie nie będzie mogła być zastosowana przez vendorów chmurowych. Żeby jednak nie było za miło – nowe edycje Javy będą dostępne za darmo (w rozumieniu postanowień licencji NFTC) wyłącznie przez rok. Po tym okresie każde wydanie zostanie przetransformowane do OTN – poprzedniej, bardziej restrykcyjnej licencji. Jeżeli więc nie stawiacie na ciągłą aktualizację wydań to nowa licencja będzie dla Was bardziej jak garniec miodu i forma roszerzonego dema.

Ciekawostka – GraalVM Enterprise dalej jest dostępny za opłatą. Czyżby Oracle czuło, że ten produkt potencjalnie rokuje lepiej jako źródło przychodu?

Ostatnią zapowiedzią ze strony Oracle jest nowy portal dla społeczności programistów dev.java. I o ile wygląda on dosyć… siermiężnie, to jeśli chodzi o zawartość jawi się jako najlepsze (a przynajmniej najlepiej skondensowane i najwygodniejsze) źródło wiedzy o Javie jako języku. Znajdziecie tam nie tylko dokumentacje języka, ale także uzyskacie możliwość ściągnięcia najnowszych binarek JDK. Strona zawiera także masę artykułów poradnikowych, odnośników do zewnętrznych zasobów (jak np. podcasty i videocasty), a już niedługo pojawić ma się też interaktywny shell, pozwalający na pobawienie się językiem z poziomu przeglądarki.

Jako, że już wspomnieliśmy oraclowe podcasty – klasycznie już polecamy inside.java. Jeżeli preferujecie formę “gadających głów”, jest to chyba najlepsze miejsce w którym możecie dowiedzieć się szczegółów na temat nowego wydania.

Źródła

2. Java 17 – najciekawsze posty ze strony społeczności 🧑‍💻

Jak już wspomnieliśmy we wstępie, oczywiście nie tylko Oracle postanowił oświetlić się w blasku nowego wydania. Mam wrażenie, że społaczeność od dawna bawiła się nowym LTSem i przygotowywała materiały, aby móc je wypuścić jak najbliżej samej premiery nowej wersji języka.

Zatem klasycznie już możemy dostać przegląd nowości w zakresie bezpieczeństwa, regularnie dostarczanych przez Seana Mullana. Mamy do czynienia z dość wyjątkową sytuacją – dawno nie było wydania, w którym zmiany w tym zakresie byłyby aż tak “medialne”. Mam tu na myśli temat SecurityManagera, którego deprekacja należy do najbardziej kontrowersyjnych aspektów nowego wydania. Sean zwraca jednak również uwagę, że zarówno kolejny krok w stronę pełnej enkapsulacji “jądra” Javy, jak i sealed classy, mają bardzo pozytywny wpływ na bezpieczeństwo aplikacji. Nie brakło też dobrego słowa w kierunku ulepszenia filtrów deserializacyjnych. Poza wspomnianymi dużymi JEPami, post stanowi także kumulację wszelkich drobniejszych zmian w kontekście kryptografii – a tych jak zawsze nie brakuje. Po szczegóły zapraszam do oryginalnego posta.

For The Good Of The Country - Dilbert by Scott Adams

Po wzięciu pod lupę aspektu bezpieczeństa, następnym przystankiem będzie wydajność. Okazuje się bowiem, że i pod tym względem JDK 17 przynosi interesujące zmiany. OptaPlanner – firma zajmująca się rozwiązywaniem odpowiedników “problemu plecakowego” z realnego świata (bo niby czym innym jest efektywne zarządzanie zasobami w dużych przedsiębiorstwach?) – zdecydowała się przetestować, jaki jest uzysk z migracji na nowego LTSa. Według ich testów możemy mówić o niemal dziesięcioprocentowym wzroście wydajności w stosunku do JDK 11. Oczywiście, jak to z benchmarkami, sugeruję patrzeć na ich wyniki z przymróżeniem oka. Trzeba jednak przyznać, że firma dość dobrze opisała swoją metodologię, więc na pewno warto choć spojrzeć na ich rezultaty. Zwłaszcza, że porównują też działanie poszczególnych GC już w ramach samej Javy 17.

A jak już o “odśmiecaczach” mowa – bardzo dobrą analizę zmian w takowych dostarczył blog Thomasa Schatzla, jednego z kontrybutorów Javy. Skupia się on na szczegółach Parallel GC oraz G1, przedstawiając jakie optmalizacje zostały do nich wprowadzone w celu uzyskania przyspieszenia, o którym mieliście okazje dopiero co przeczytać. Jeśli chodzi o zmiany w Shenandoah, o nich możecie dowiedzieć się też ze strony RedHata. Jeżeli zaś jesteście ciekawi detali tego, co dzieje się obecnie w ZGC – już niedługo powinno pojawić się takowe na blogu Pera Lidena. Na dzień pisania tej edycji jest ona ciągle “w toku”. Warto jednak czekać, gdyż Per zawsze bardzo przejrzyście opisuje zakres wprowadzonych zmian.

The Best Garbage Collection for JMeter | DevsDay.ru — Akurat nie udało mi się znaleźć żadnego dobrego opracowania Epsilona…

Źródła

3. Kotlin Reflekt – Refleksja w czasie kompilacji 🤯

Ok, na koniec, w celu odpocznku od tej całej Javy 17 – mamy zapowiedź wyjatkowo ciekawej biblioteki od JetBrains mogącej sporo namieszać w kotlinowym ekosystemie.

Reflekt (bo o nim tu mowa) to biblioteka do refleksji działająca w czasie kompilacji (!). Zamiast polegać na JVMowym mechaniźmie refleksji, Reflekt wykonuje analizę statyczną kodu aplikacji za pomocą kotlinowego kompilatora, umożliwiając dalsze używanie znajomego i powszechnie używanego Reflection API odbić, bez faktycznego używania refleksji. Na dobrą sprawę, mamy do czynienia z generycznym syntezatorem efektów działania tego mechanizmu, uruchamianym podczas tworzenia binarki.

val objects1 = Reflekt.objects().withSupertype<AInterface>()
        .withAnnotations<AInterface>(FirstAnnotation::class, SecondAnnotation::class).toList()

Projekt jest efektem współpracy działu R&D JetBrains oraz zespołu pracującego nad Kotless (kotlinowym frameworkiem serverless). Jak piszą sami twórcy, głównym powodem powstania Reflekta była chęć obsługi GraalVM w aplikacjach serverless, ale Reflekt ma też ułatwić użycie tej technologii w np. w bardzo mocno opartym na refleksji Springu. Do tej pory każdy projekt, który chciał pozbyć się refleksji musiał samodzielnie “hakować” refleksje za pomocą np. annotation processorów. Reflekt stanowić ma reużywalny komponent.

Jeśli chcecie zobaczyć jak to działa – przykłady znajdziecie tutaj.