Wszystko, co mogliście przegapić w Javie w 2022 – JVM Weekly #119

1. Rok, w którym GraalVM stał się „rzeczą”

Jeżeli ktoś kazałby mi wybrać, co moim zdaniem było największym wydarzeniem w 2022 roku dla JVM, wskazałbym wszystko to, co działo się w świecie GraalVM. Mijający rok bardzo rozjaśnił bowiem miejsce, jakie zajmuje GraalVM w ekosystemie Javy.

Przez lata tym, co najbardziej blokowało adopcję GraalVM, był bowiem jego niejasny model licencyjny. O ile projekt alternatywnej dla JVM, uniwersalnej maszyny wirtualnej (jednej by wszystkimi rządzić 💍) zawsze mocno powiązany był z JDK, o tyle w praktyce relacja między tą dwójką nigdy nie była klarowna. W inny sposób się go rozwijało, inaczej był dystrybuowany, ale co najważniejsze – opierał się na zupełnie innej licencji niż OpenJDK. Zarówno wydanie społecznościowe (GraalVM Community Edition), jak i korporacyjne (GraalVM Enterprise Edition) pozostawały własnością Oracle.

Podczas JavaOne 2022 ogłoszono zaś, że Oracle oddaje GraalVM Community Edition w ręce społeczności i stanie się nareszcie częścią OpenJDK (Enterprise Edition pozostanie pod starą licencją). Jak duża jest to zmiana dla GraalVM, ale również Project Leyden i reszty ekosystemu JVM opisywałem kiedyś w dłuższym tekście. TLDR: temat kompilacji AoT w Javie wreszcie zaczyna po lat pewnego miotania się nabierać porządku.

Dodatkowo, wiemy już, pod jaką „parasolką” całe te przenosiny przebiegać. GraalVM CE jest szerszym ekosystemem, a tylko część dotycząca Javy będzie migrowana do JDK. Dlatego do zaprojektowania i przeprowadzenia całości powołano specjalną inicjatywę – projekt Galahad. Pierwszym krokiem będzie wprowadzenie JDK drugiego (a właściwie trzeciego) kompilatora JIT. Wiadomo też już, że cały GraalVM zmieni swój cykl wydawniczy tak, by zsynchronizować się z JDK.

Poza zmianami organizacyjno/licencyjnymi, duże nowości pojawiły się w samej platformie. Poza ciągłą pracą nad performance i wsparciem nowych środowisk uruchomieniowych (min. procesorów M1), zabrano się za modularyzację platformy. Do tej pory niezależnie od tego, który z wielu języków wspieranych przez GraalVM był przez nas używany (a pewnie w 90% przypadków jest to jednak Java), bazowy obraz zawierał pliki niezbędne do uruchomienia np. JavaScript czy LLVM. Z drugiej strony, taki Python czy Ruby musiały być już bezpośrednio doinstalowywane. Sytuacja została posprzątana w 2022 i teraz każdy z dodatkowych modułów musi być doinstalowywany – „goły” GraalVM wspiera wyłącznie Javę (co pewnie bardzo ułatwia pracę zespołu odpowiedzialnego za Galahada). Zaletą tego rozwiązania jest to, że udało się mocno zredukować bazowy rozmiar obrazu, kosztem kilku dodatkowych komend dla programistów LLVM czy JS. Dla większego dobra.

GraalVM AD 2022 to też lepsza obsługa bibliotek zewnętrznych. Jako, że GraalVM tworzy statyczny obraz zawierający pre-kompilowane klasy, na etapie tworzenia artefaktu wynikowego zmuszony jest do wyczyszczenia tych klas, które nie są używane z poziomu wejścia aplikacji. O ile brzmi to rozsądnie, to w Javie dość mocno rozpanoszył się mechanizm refleksji, który sprawia, że aplikacja może odnieść się do arbitralnie dowolnej klasy dostępnej na classpath.

A co jeśli takowego classpath nie ma? Szczęśliwie, możemy przekazać GraalVM listę klas, których nie powinien czyścić (programiści Androida znają ten mechanizm pewnie z ProGuarda). W wypadku bibliotek third-party prowadziło to jednak do duplikacji pracy, gdy każdy projekt musiał w zasadzie robić to samodzielnie. Dlatego w 2022 pojawiło się GraalVM Reachability Metadata Repository, społecznościowe centrum pozwalające dzielić się takimi definicjami – trochę jak to ma miejsce np. z typami w TypeScripcie. Co najważniejsze – GraalVM Native Build Tools mogą zostać skonfigurowane, aby automatycznie zaciągać te definicje do znalezionych w kodzie zależności.

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. Inwestycje gigantów BigTech w Javę

Pewnie większość kojarzy projekt AdoptOpenJDK, który powstał jako efekt wysiłków społeczności walczącej o “wolną” implementacje JDK w momencie, kiedy Oracle parę lat temu uczynił Oracle JDK płatnym dla użytku komercyjnego. AdoptOpenJDK początkowo rozwijany był przez społeczność JUGów z całego świata, by ostatecznie trafić pod skrzydła Eclipse Foundation. W efekcie AdoptOpenJDK zostało przechrzczone na na Eclipse Adoptium (JDK jest znakiem towarowym należącym do Oracle), a do opieki nad projektem powstała Adoptium Working Group. Oczywiście, ktoś nad tym kodem musi pracować i go utrzymywać, dlatego Adoptium Working Group posiada swoich korporacyjnych sponsorów. I to takich naprawdę dużych, a w 2022 mieliśmy związane z tym kilka ogłoszeń.

Taki np. RedHat (mimo że przez wiele lat posiadał własne OpenJDK) w 2022 ogłosił, że zamierza skupić się na Temurinie. Oznacza to, że klienci firmy mogą liczyć na oficjalny support tego wydania i to właśnie ono ma być dostępne we wszystkich produktach firmy. Jest to trochę inny model niż np. Microsoftu, który używa Temurina jako buildu dla JDK 8, ale do późniejszych JDK posiada swoje własne warianty.

RedHat jednak zawsze z rozwojem OpenJDK w większym lub mniejszym stopniu się kojarzył. Dużo większym było ogłoszenie od Google. Firma zapowiedziała bowiem, że dołącza do grupy roboczej Adoptium jak Członek Strategiczny. Google nie ograniczyło się tylko i wyłącznie do rzucania w JDK workami pieniędzy, ale wraz z Alibabą zaczęli pracować nad przyspieszeniem startu platformy.

Wspomniany już Microsoft postanowił pójść jednak jeszcze szerzej. Są czasem takie nagłówki, po których przeczytaniu muszę upewnić że wszystko dobrze zrozumiałem. W pierwszej chwili informacja, że Microsoft staje się częścią ciała standaryzującego zarówno Jakarty EE, jak i MicroProfilu wydała mi się być po prostu… jakaś nierealistyczna.

Jest to jednak dość naturalny ruch: Microsoft schylił się po prostu po nisko wiszące pieniądze. Azure będzie pierwszą chmurą, która zapewni natywne usługi serwerów aplikacyjnych Javy. Już dzisiaj dostępne zostaną zarówno WebLogic, jak i WebSphere czy JBoss EAP.

Aczkolwiek w temacie wsparcia chmurowego dla Jakarty, dalej uważam, że najciekawszym nowym projektem roku była Payara Cloud. Działa ona tak, że bierzesz swojego *.war zgodnego ze specyfikacją Jakarta Web Profile, uploadujesz go na chmurę i… gotowe. Jeśli spojrzymy na Serwery Aplikacyjne jako środowisko uruchomieniowy dla aplikacji (czym w zasadzie są), to podejście „wrzucam jar/war i zapominam o mojej aplikacji cloud-native” wydaje się być aż nazbyt kuszące.

Po prostu ponownie historia zatoczyła koło.

3. JDK 11 w Androidzie

W 2022 premierę miał Android 13. Nie słyszeliście o tym? Nic dziwnego. Kiedyś była to naprawdę duże wydarzenie, ale dziś premiera w tym wypadku oznaczała „zmergowanie” całości do głównej gałęzi AOSP (Android Open-Source Project) oraz wypuszczenie nowej wersji na Pixele. Potem zaś zaczyna się okres oczekiwania na ruchy reszty graczy rynkowych – trochę jak to ma miejsce w wypadku Kernela Linuxa. Również lista nowości jest z nim dość zbliżona – większość zmian odbywa się teraz „pod maską”.

Dlaczego więc o tym piszę? Otóż wraz z „trzynastką” świętowaliśmy przejście Androida na OpenJDK 11, wprowadzając do platformy min. Możliwość używania var, VarHandle z java.util.concurrent czy wielu innych pomocniczych API (jak Optional.ifPresentOrElse() ❤️). Widać, że wyniki procesu Google/Oracle z 2021 rozwiązały twórcom ręce i powoli będą wdrażać nowości z Javy do Androida.

4. Helidon Níma – pierwszy Framework Loom-first

Project Loom nie schodził z języków w zasadzie przez większość 2022, ale jeśli miałbym wybrać jedną zapowiedź, która jest najbardziej ekscytującą w tym kontekście, to byłby to Helidon Níma. Okazuje się bowiem, że szykuje nam się pierwszy(?) framework, w którym Loom nie będzie doklejonym dodatkiem, a „First-Class Citizen”.

Na razie ukazała się wersja Alfa, a na pełną przyjdzie nam jeszcze poczekać – twórcy zapowiedzieli bowiem, że pracę nad nią powstaną mniej więcej do końca tego roku, kiedy należy się spodziewać jej stabilnego wydania, równoległego do Helidona 4.0. Jak na tak wczesny etap otrzymaliśmy już całkiem sporo szczegółów technicznych – towarzysząca postowi premierowemu publikacja Thomasa Langera skupia się na tym, jak Níma na tym etapie prezentuje się w porównaniu z MicroProfilowym Helidonem, a także z bezpośrednią konkurencją, za jaką twórcy uznają Netty’ego. Jak można przeczytać, jednym z celów Nímy jest właśnie całkowite wyrugowanie Netty’ego z helidonowego ekosystemu.

5. Akka zmieniła model licencyjny

Akka to w dzisiejszych czasach jeden z głównych trzonów Scali i jeden z głównych powodów, dla których to właśnie tym językiem interesują się firmy. Jest to jedna z najlepszych w całej branży implementacji modelu aktorowego, który dzięki wsparciu dojrzałej (i dobrze znanej w branży) platformy – jaką jest JVM – stanowiła prawdziwie bardzo kuszącą kombinacje. Dlatego też tak dużym echem w branży odbiła się w świecie programistycznym wiadomość, że od wersji 2.7 Akka zmienia model licencyjny z Apache 2.0 na BSL v1.1 (Business Source License), stworzonej przez MariaDB. Zmiana licencji oznacza w zasadzie zamknięcie etapu rozwoju Akki w oparciu o tak zwany „Open Core”.

Co BSL oznacza dla Akki w praktyce? Otóż nowe wersje będą w dalszym ciągu publikowane pod Apache 2.0, jednak ze sporym opóźnieniem – dopiero po trzech latach. Do tego czasu każda nowa wersja będzie co prawda udostępniana wraz ze źródłami, ale za darmo będzie wolno z niej korzystać wyłącznie na środowiskach nieprodukcyjnych. Jeżeli będziemy chcieli użyć Akki w systemie produkcyjnym, a roczny przychód naszej firmy przekracza 25 milionów dolarów, niezbędne będzie uiszczenie opłat licencyjnych. Ich ceny zaczynają się od około $2,000 USD za rdzeń procesora, definiowany jako rdzeń sprzętowy / vCore / vCPU. Jeżeli chcemy zmodyfikować Akkę na swoje potrzeby, licencja wyniesie nas $72,000 USD.

6. AWS Lambda SnapStart

Czyżbyśmy zapamiętali 2022 jako rok, w którym problem „zimnego startu” Java został ostatecznie rozwiązany, przynajmniej na AWSie? Jest na to spora szansa, ponieważ końcem roku Amazon – nieco z zaskoczenia – pokazał AWS Lambda SnapStart.

Wykonanie każdej funkcji Lambda składa się z trzech faz – Init, Invoke oraz Shutdown. Bootstrap środowiska w ramach pierwszej z nich polega na przygotowanie całego środowiska do stanu, w którym jest w stanie przyjmować ruch – jest to właśnie wspomniany Cold Start. Aby uniknąć powtarzania tej operacji, SnapStart w tym momencie stan pamięci lambdy zapisuje i odkłada „na później”, gdy nasza funkcja nie będzie wystarczająco rozgrzana. Dzięki temu czas uruchomienia zostaje zredukowany do minimum. Całość pod spodem używa świeżutkiego (i wciąż rozwijanego) javowego API CRaC, które pomaga w sytuacji, gdy niezbędne jest odświeżenie snapshotu – AWS Lambda udostępnia odpowiednie hooki.

Jeśli temat Was zaciekawił, rozpisałem się kiedyś w tej kwestii w całkiem długim tekście, min. lepiej opisując wspomniany CRaC. Przedstawiłem w nim całą drogę, którą społeczność musiała przejść przed stworzeniem SnapStart.

7. Jakarta EE nareszcie ruszyła do przodu

Rzekłbym… nareszcie.

Od paru lat Jakarta EE pozostawała w dziwnym miejscu. Ze względu na brak praw do pakietu javax, cała społeczność skupiała się na przenosinach na nowy namespace – jakarta. Ostatnie większe wydanie – Jakarta EE 9.1 z 2021 – skupiało się na dopinaniu zmian związanych z tym przejściem. W 2022 mieliśmy zaś okazję świętować premierę Jakarty EE 10, którą można uznać za pierwszy prawdziwy krok do przodu od czasu rebrandingu projektu.

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… takich z lat 200X.

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ć.

To jednak nie wszystko. Od lat trwa proces nieustannego odchudzania korporacyjnej Javy, i w tym kierunku poszedł też standard CDI – Context and Dependency Injection. 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, ż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.

Ogólnie.. dużo się dzieje. Mam nadzieje, że 2023 będzie równie udanym dla programistów Jakarty EE. Teraz, kiedy większość ekosystemu – ze Springiem, Helidon czy jOOQ na czele – przepisało się już na nową „otwartą” wersję, twórcy standardu będą w stanie wreszcie udowodnić, że warto się nim interesować.

8. WildFly rezygnuje z “Release Trainu”

Pozostając w temacie Jakarty EE, kolejna informacja dotyczy WildFly. Jednocześnie ze względu na to, jak mocno idzie pod prąd trendom, jeśli chodzi o sposób releasowania oprogramowania, powinna być interesująca dla nieco szerszej rzeszy ludzi niż typowe ogłoszenia związane z Javą EE.

Otóż w dobie, gdy większość projektów przechodzi na regularny “pociąg releasowy”, WildFly zdecydował się na swoisty krok w tył i oparcie swoich nowych wersji o zdefiniowane zbiory funkcjonalności. Jest to swoisty powrót do korzeni, gdy nowe wydania serwerów aplikacyjnych były znacznie rzadsze i wiązały się właśnie z dużymi podbiciami standardu, nie konkretnymi datami w kalendarzu.

Jedną z dużych funkcjonalności (poza aktualizacją do Jakarta EE 10), jakie „dowiózł” w 2022 WildFly jest S2I – Source-to-Image (S2I). Mówimy tutaj o zestawie narzędzi, na który składają się nowe bazowe obrazy dla javowych LTS w wersji JDK11 i JDK17 (brak ósemki), nowy plugin mavenowy, zestaw chmurowych funkcjonalności o wdzięcznej nazwie Galeon oraz nowa wersja wsparcia dla Helm dla WildFly 2.0.

Ja wiem, że Cloud-Native serwer Enterprisowej Javy brzmi dla wielu jak kuriozum, widać jednak, że twórcy WildFly chcą jeszcze trochę powalczyć na nowym terytorium. Ten serwer aplikacyjny zawsze uchodził za tego najbardziej “światowego” członka społeczności Jav… Jakarta EE, także podejrzewam, że wśród jego użytkowników znajdą się tacy, którzy będą mieli ochotę z S2I poeksperymentować.

9. Uczenie Maszynowe trafiło do standardu Javy

Był takie okres w 2021, gdzie dość dynamicznie zaczynały się pojawiać rozwiązania do Machine Learningu celujące w programistów Javy. Zarówno Oracle, jak i LinkedIn próbowały zaprezentować społeczności swoje rozwiązania, ale jak głośno było na początku, tak ostatnimi czasy i o Tribuo, i o Dagli jest relatywnie cicho. Nie zmienia to jednak faktu, że przestrzeń ML-owa jest zbyt łakomym kąskiem żeby go ot-tak odpuścić i oddać Pythonowi.

Javowy ekosystem nie poddaje się więc, o czym świadczyć może formalna akceptacja dla prac nad JSR-381 Visual Recognition (VisRec) Specification. Wbrew dość mylącej nazwie, ma to być standard wysokopoziomowego API dla zarówno podstawowego uczenia maszynowego (ML), jak i klasyfikacji obrazów i rozpoznawania obiektów. JSR 381 ma zapewnić wspólnego API dla MLa, wspólnego dla różnych domen. Jego referencyjna implementacja jest oparta na bibliotece DeepNetts, ale całość już w tym momencie wspierana jest przez Deep Java Library, bibliotece stworzonej przez Amazon.

10. Alpaquita Linux – OS dedykowany pod skonteneryzowaną Javę

W 2022 BellSoft – twórcy Liberia JDK – postanowili stworzyć nową, referencyjną dystrybucję Linuxa przeznaczoną bezpośrednio do uruchamiania Javy w kontenerach. Na pierwszy rzut oka brzmi to trochę jak strzelanie z armaty do muchy, ale w tym szaleństwie jest metoda. Twórcy wzięli bowiem minimalistycznego Alpine, który sam w sobie dodaje naprawdę minimalny narzut (używałem go w praktyce, jest prawie niezauważalny), ale zmodyfikowali w sposób, który zapewnić ma w wypadku aplikacji JVM-owych znacznie lepsze bezpieczeństwo i wydajność.

BellSoft min. stworzył zmodyfikowany wariant alokatora pamięci musl, używanego także przez Alpine, a którego wsparcie zostało dodane całkiem niedawno w JDK 16. Całość nazwali Alpaquita Linux, dodali wsparcie LTS i zapakowali razem ze wcześniej wspomnianym Liberica JDK. Opublikowali też trochę liczb i benchmarków, które mają potwierdzać ich wersję, że udało im się stworzyć najlepiej dostosowany do potrzeb javy i kontenerów dystrybucje Linuxa.

Najciekawsze wydania roku – języki JVM

Java 18

Po JDK 17, które jak pewnie wielu z Was pamięta było wydaniem typu LTS (Long-Time Support), zakres “osiemnastki” nie należy do jakichś olbrzymich, ale i tak jest w niej trochę rzeczy, nad którymi warto się pochylić.

JDK 18 przyniósł bowiem 408: Simple Web Server (wbudowania w Javę minimalistycznego Web Server) oraz 413: Code Snippets in Java API Documentation (wprowadzający znacznik @snippet do JavaDoc, co ma na celu uprościć dołączanie przykładowego kodu źródłowego do dokumentacji API).

Oprócz tego JDK 18 to parę zmian pod maską (416: Reimplement Core Reflection with Method Handles, 400: UTF-8 by Default oraz 418: Internet-Address Resolution SPI) a także JEP 421: Deprecate Finalization for Removal – Deprekacja Finalizerów, która spotkała się z masą kontrowersji ze strony społeczności, ale i tak została „przepchnięta” ku chwale projektu Loom.

Java 19

Wydanie to z jednej strony wydawać się może czymś małym, jednak niech nie zmylą Was pozory jedynie pojedynczej stabilnej funkcjonalności – mamy bowiem do czynienia z jednym z najważniejszych nowych JDK od lat, skłonny jestem stwierdzić, że nawet od czasu JDK 9 z jego systemem modułów. Po raz pierwszy bowiem mamy okazję wersje Preview projektów, które stanowić będą przyszłość JVM.

W JDK 19 zobaczyliśmy wreszcie też pierwszy preview oczekiwanego od lat Looma. Społeczność bawi się całością w najlepsze od dłuższego czasu, a teraz również programiści obawiający się samodzielnie kompilowanych wersji będą mogli wypróbować wirtualne wątki i bezboleśnie sprawdzić, czy całość wytrzymała cały hype z jakim wiązały się kolejne zapowiedzi projektu. Równocześnie, długo oczekiwana Strukturalna Współbieżność, będąca częścią Looma również trafił do inkubacji, i stanowiąc naturalne uzupełnienie Wirtualnych Wątków.

Kolejny gracze wagi ultraciężkiej, 424: Foreign Function & Memory API oraz 426: Vector API czyli efekty Projektu Panama, również pojawił się w nowym wydaniu JDK. Przed nami materializuje się następca JNI, który zapewnić ma nam nową, lepszą integrację z natywnym kodem i pamięcią.

Obserwowaliśmy też dalszy rozwój rozwiązań znajdujących się pod parasolką Project Amber, takich jak 427: Pattern Matching for switch czy 405: Record Patterns (Preview).

Oprócz aktualizacji dużych projektów, twórcy Javy pokusili się o wsparcie dystrybucji uruchamianych na procesorach z rodziny RISC-V. Platforma ta naprawdę ostatnio jest a językach – min. w tym tygodniu Google ogłosiło, że chce uczynić z niej jeden z trzonów Androida.

Więcej o JDK 19 znajdziecie tutaj.

Kotlin 1.7

Kotlin nie miał w tym roku lekko. JetBrains zmuszone było migrować zespół pracujący nad językiem z Federacji Rosyjskiej, co z pewnością nie pomogło na szeroko rozumianą produktywność. Nie znaczy to jednak, że 2022 nie wprowadził żadnych nowości do języka. Ukazał się min. Kotlin 1.7

Najważniejszą nowością wydaje się z pewnością wersja Alfa kompilatora K2. To właśnie K2 jest przyszłością Kotlina. Twórcy języka (platformy?) chcą, aby w niedalekiej przyszłości być w stanie w realny sposób stworzyć z Kotlina rozwiązanie prawdziwie multiplatformowe, bez potrzeby wielokrotnej implementacji tych samych funkcjonalności. Wersja Alfa na razie wspiera wyłącznie JVM i jest jeszcze dość mocno ograniczona, ale pierwsza testowa edycja to bardzo ważny krok dla całego projektu.

Z nowości z pewnością wymienić trzeba też inkrementalną kompilacje za pomocą Gradle. Twórcy chwalą się, że ich wewnętrzne testy wykazały poprawę o ponad 80% dla zmian po trafieniu do cache. Kotlin od lat ma opinie dosyć przyciężkawego, dlatego każdy ruch w stronę poprawy Developer Experience (a takimi są w końcu wszelkie poprawki procesu kompilacji) są bardzo na miejscu.

Jeżeli chodzi zaś o rzeczy związane z syntaxem języka, to zdecydowanie to wydanie stoi pod znakiem dalszego pokrycia sytuacji brzegowych, z którymi radzić sobie musi system typów Kotlina. Nowe wydanie przynosi bowiem min. typy ostatecznie nie-nullowalne oraz wnioskowanie typów w ramach tzw. Builderów. Wprowadzono też operator underscore, pozwalający na automatyczne wnioskowania o typie generycznym, gdy znane są pozostałe argumenty.

Zaraz przed sylwestrem ukazał się też Kotlin 1.8, ale ten nie doczekał się jeszcze nawet oficjalnego announcementu poza aktualizacją dokumentacji, więc nie zaliczam go do dziedzictwa 2022 i zajmę się dopiero za tydzień.

Groovy 4.0

Dla Groovy’ego przyszły chude lata – nowości w tym języku dość słabo rezonują ze społecznością. Sam muszę przyznać, że pomimo tego że regularnie śledzę świat technologii, to wydanego parę lat temu Groovy’ego 3.0 przegapiłem i dowiedziałem się o nim grubo po oficjalnej premierze. Na wersję 4.0 byłem już trochę przygotowany, ale ona też zdecydowanie nie wybrzmiała wśród programistów – jej zeszłoroczna premiera przeszła maksymalnie bez echa. Trochę się nie dziwie – “czwórka” to jednak taka “ciepła woda w kranie” jak Switch expressions, Sealed types, JavaShell czy Rekordy.

Co prawda można w niej znaleźć parę ciekawszych perełek, ale większość z nich (jak choćby GINQ – Groovy-Integrated Query) czy intrygujące Groovy Contracts na razie znajdują się w inkubacji. Iskierką nadziei jest jednak to, że Groovy 5.0 zapowiada się dzięki nim całkiem smakowicie. Możliwe, że aby zrobić duży krok do przodu, twórcy musieli najpierw ulepszyć kompatybilność z Javą. I co prawda nie wierzę, że Groovy kiedykolwiek odzyska pozycję, którą miał jeszcze kilka lat temu, ale może jeden z ciekawszych języków JVMa jeszcze nas kiedyś zaskoczy.

Clojure 1.11

Ostatnim, ale zdecydowanie nie najmniejszym z nowych wydań jest nowa wersja języka Clojure! Czasy, kiedy byłem z Clojure na bieżąco trochę już minęły, ale jako że poprzednia nowa wersja pojawiła się jeszcze w roku 2018 „clojurowcom” przyszło trochę poczekać. Zakup twórców języka przez Nubank w 2020 nie przyspieszył jakoś mocno rozwoju języka, ale też należy pamiętać, że niektóre narzędzia są „kompletne”.

Clojure 1.11 zapewnia nową składnię wywoływania argumentów słów kluczowych – funkcje, które przyjmują argumenty słów kluczowych, mogą teraz otrzymywać mapę zamiast par klucz/wartość. Pojawiła się też nowa przestrzeń nazw (w uproszczeniu – pakiet) clojure.math, zapewniająca funkcje opakowujące metody dostępne w java.lang.Math dla “longów” i “dubli”. Dodatkowo, istnieje teraz opcja aliasowanie przestrzeni nazw w sposób, który nie powoduje błędu, jeżeli dany namespace nie jest dostępny. Do samego core języka dodano zaś sporo nowych funkcji.

A na końcu tej sekcji żart. Po czym poznasz programistę Clojure? Bo Ci o tym powie!

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!

Najciekawsze wydania roku – frameworki i biblioteki

Spring Framework 6.0 i Spring Boot 3.0

Końcówką 2022 ukazały się Spring Framework 6.0 oraz Spring Boot 3.0. I choćby nie wiem jak wiele zmian przynosiły same w sobie, to z pewnością największą rewolucją jest porzucenie wsparcia starszych wersji Javy. I kiedy mówię tutaj „starsze”, na myśli mam nie Jave 1.6, nawet nie Java 1.8 ale nawet… Jave 16. Nowy Spring do działania wymaga Javy 17. Pivotal nie poszedł tutaj na żadne kompromisy i nowego „majora” projektów przystosował do działania wyłącznie z najnowszym dostępnym w tej chwili wydaniem LTS.

Nowa Java to jedno, ale Spring Framework 6.0 przynosi również nową Jakarte w wersji 9.1+. Warto o tym wiedzieć, ponieważ proces migracyjny może okazać się tutaj (co dla wielu będzie pewnie zaskoczeniem) trudniejszy niż w wypadku Javy. Przypominam bowiem o tym, że Jakarta EE 9.1+ to ta edycja, która pozbyła się pakietu javax.* na rzecz jakarta.*, w ten sposób uchodząc z zasięgu Oracle i należących do nich trademarków.

Jeśli śledziliście wiadomości o nowym Springu od jego pierwszych zapowiedzi, mam dla Was złą nowinę – okazuje się bowiem, że długo oczekiwane wsparcie JPMSa, systemu modułów Javy, nie będzie gotowe na premierę. Jak przyznają twórcy, można się spodziewać jego pojawienia w późniejszych wersjach, ale pierwsza wersja Spring Framework 6 skupia się szczególnie na wsparciu kompilacji Ahead-of-Time i GraalVM, a moduły utrudniałyby ten proces, komplikując tak zwaną „analizę osiągalności”. Należy bowiem pamiętać, że w odróżnieniu od nowych graczy na rynku frameworków jak Quarkus, Helidon czy Micronaut, Spring bardzo, bardzo mocno opiera się na Reflection API. Dla niego więc proces wsparcia dla GraalVM, który refleksji nie wspiera jest więc znacznie trudniejszy.

Dłuższą przeglądówkę nowego Springa mojego autorstwa znajdziecie tutaj.

SLF4j 2.0

Podejrzewam, że praktycznie każdy z czytających ten newsletter (przynajmniej z tych będących w branży już parę lat) choć raz miał przyjemność dokładania do projektu slf4j. Nazwę tą rozwija się jako The Simple Logging Facade for Java i taką właśnie jest jej rola. Dekadę temu, log4j w swojej pierwszej wersji był frameworkiem mocno skomplikowanym, o niskopoziomowym API.

Od czasu świetności slf4j branża jednak trochę wyewoluowała. Najpierw pojawił się Logback, a następnie pojawił się log4j2, który przyniósł API kompatybilne z slf4j, ale już bez dodatkowego narzutu abstrakcji. W międzyczasie pojawił się też java.lang.system.Logger, czyli drugie podejście twórców JDK do tematu logowania – dużo bardziej udane. To wszystko składa się na fakt, że lata świetności slf4j ma chyba za sobą.

Co jednak przynosi slf4j 2.0? Pewnym zmianom uległo API (mocno przemodelowane zostały niektóre buildery oraz dołożono Fluent Logging API), ale z pewnością największa rewolucja wydarzyła się pod maską. Wraz z nową wersją, slf4j pozbył się wsparcia dla JDK mniejszych niż JDK 8 – nie są więc tak „ambitni” jak twórcy np. Springa, ale też ze względu na swoje mocne zakorzenienie w przeszłości jest to dość rozsądny krok. Jednak również Ci używający nowszych JDK 9+ dużo zyskają na migracji – w odróżnieniu od Springa, slf4j doczekał się bowiem wsparcia dla modułów JPMS, dzięki czemu łatwiej będzie się go używało w zmodularyzowanych projektach.

Hibernate 6.0

Hibernate 6.0 to edycję, która jest pierwszym “majorem” Hibernate od roku 2011. Nie oznacza to oczywiście, że rozwój biblioteki stał w miejscu – każda z regularnie wydawanych minorów 5.x przynosiła nowości. Ostatnimi czasy jednak więcej mówiło się o pobocznych projektach, takich jak choćby Hibernate Reactive.

Nowy Hibernate to przede wszystkim nowe adnotacje, które porzuciły swoje XMLowe korzenie i doczekały się sporej ilości zmian min. lepsze type-safety. Dużym krokiem do przodu jest też Semantic Query Model (SQM) – nowy parser zapytań o encje, który obsługuje zarówno JPQL, jak i Criteria API. Nowy parser będzie znacznie bardziej elastyczny, dzięki czemu zapewniamy lepszą translację zapytań o encje w języku SQL. Dodatkowo, pojawiła się poprawa wydajności poprzez zmianę z odczytu kolumn po nazwie na odczyt według pozycji w ramach ResultSetu oraz aktualizacja używanego przez Hibernate parsera z ANTLR.

Bardzo dużą zmianą jest też migracja Hibernate na Jakartę EE i porzucenie starych API związanych z Java EE. To właśnie min. z tym wiąże się podbicie dużej wersji aplikacji – z wiadomych względów, pojawia się potrzeba migracji z przestrzeni nazw javax.persistence do jakarta.persistence.

Ktor 2.0

Ktor to rozwijany przez JetBrains referencyny Framework dla Kotlina do tworzenia aplikacji webowych. Nowa edycja nie bez powodu ma duży “numerek” 2.0 – wiele API (np. Pluginów) zostało przebudowane w zasadzie od podstaw, zgodnie z ostatnim duchem Kotlin Multiplatform Ktor zaczął wspierać min. platformę Native. Z mojej perspektywy jednak najciekawszą nowością jest (nareszcie) wsparcie Retries.

AWS SDK dla Kotlina ze wsparciem Korutyn

Na koniec, jeżeli używacie AWS i Kotlina, to bardzo polecam Wam wypróbować AWS SKD w wersji Kotlinowej. Opublikowana w tym roku wersja „natywną” dla języka JetBrains wspiera bowiem korutyny, co jest o tyle kluczowe, że AWS SDK składa się w zasadzie z samych operacji I/O. Miło ze strony AWS, że zdecydował się na specjalną edycję Kotlinową – o ile kompatybilność tego języka z Javą pozwala poradzić sobie w większości sytuacji, o tyle dobrze, żeby po 2022 nie trzeba było się do tego za często uciekać – w końcu stabilne korutyny mają już kilka dobrych lat.

Vaadin 23

Czym jest Vaadin, wielu z Was zapyta? W czasach, kiedy wszystkim wydawało się, że generowanie frontendu z Javy to jest rewelacyjny pomysł (a biorąc tymczasowy szał na Railsy – trudno się tym ludziom było dziwić), w świecie JVMa powstał Vaadin, który miał zająć się minimalizacją znajomości frontendu przez osoby chcące stworzyć pełną aplikację webową. Czasy mamy trochę inne i trochę nauczyliśmy się, że dedykowany inżynier frontendu to jednak jest dobry pomysł, ale nie sprawia to, że Vaadin daje za wygraną.

Nowe wydanie min. porzuca wsparcie dla Javy starszej niż 11, a także zmiany w design systemie Vaadin to jednak nie tylko sam core, ale także cała platforma, posiadająca dwa główne, konkurencyjne Frameworki.

Pierwszym z nich jest Flow, który służy do generowania kodu JavaScript w 100% z poziomu Javy, a “dwudziestka trójka” przynosi min. pełne wsparcie npm i Vite – coraz popularniejszego narzędzia dla budowanie aplikacji frontendowych.

Drugi to zaś Hille, nowy framework webowy dla programistów Java, który łączy backend ze Spring Boot z TypeScript, dając nam “pełnostosową” aplikację, jeśli jednak frontendem się tak bardzo nie brzydzimy. Znany wcześniej jako Vaadin Fusion, Hilla oferować ma wiele możliwości upraszczających tworzenie aplikacji biznesowych, takich jak ujednolicona konfiguracja projektu dla Java i TypeScripta. Posiada też bogaty zestaw komponentów UI. Wygląda to całkiem ciekawie, aczkolwiek dzisiaj osoby poszukujące rozwiązania FullStack, pewnie zdecydują się prędzej na JHipstera.

Helidon 3.0

Helidon stanowi swoistą implementacje referencyjną dla MicroProfile i „mikro” Jakarty EE od samego Oracle. Nowa edycja wymaga do działania minimum JDK 17. Oracle idzie jak burza.w procesie wypychania użytkowników na najnowsze LTS’y – jak widać na załączonym przykładzie, przyjęli metodę kija (minimalne wspierane wydania) i marchewki (istotne nowości).

Bo za takową „istotną nowość” z pewnością uznać można wsparcie dla MicroProfile 5.0 oraz wyselekcjonowanych aspektów Jakarta EE 9.1. W jakiś sposób zabawnym jest dla mnie, że wraz z tym podbiciem również framework od Oracle pozbywa się trademarkowanej paczki javax. na rzecz jakarta.. Twórcy chwalą się, że jest to pierwszy produkt korporacji który dokonał tej zmiany.

---

Jeśli jeszcze tu jesteście – dziękuję za wytrwałość 🎉
I mam nadzieję, że 2023 będzie równie ciekawy co 2022 🤩