JVM Tuesday vol. 39

1. Wydano Spring Boot 2.5

Obrodziło nam tymi nowymi ogłoszeniami ostatnio. Każdy “Wtorek” poszczycić się może kolejną premierą.

Po wyczerpującym okresie testów oraz kilku wersjach Release Candidate, nareszcie doczekaliśmy się nowej odsłony Spring Boota. Muszę przyznać, że w momencie, gdy zobaczyłem ogłoszenie z listą zmian, nie wzbudziło to we mnie jakiegoś nadmiernego entuzjazmu. Diabeł jednak tkwi w szczegółach i zagłębiając się w release notes, znaleźć można kilka dość interesujących nowości.

Oczywiście zacznijmy od “ciepłej wody w kranie”. Nowy Spring to wsparcie dla Javy 16 oraz Gradle 7. Oczekiwany upgrade zależności, który przyda się pewnie wszystkim osobom starającym się być na “ostrzu” JVMowego ekosystemu. Sam Spring pozostaje kompatybilny z Javą 8+, co powoduje dość ciekawe reperkusje. Aktualizacji uległa bowiem jedna z zależności Springa – Jetty. Jednak mamy tutaj mały rozjazd, gdyż Jetty 10 wymaga JDK w wersji minimalnie 11. Stąd też domyślną pozostaje starsza implementacja, Jetty 9, która jest w stanie obsłużyć również wcześniejsze Javy. Ciekawe, czy w przyszłości możemy spodziewać się częściej tego typu sytuacji, biorąc pod uwagę niesłabnącą popularność “ósemki”.

To w czym nowe wydanie Springa szczególnie błyszczy, to wsparcie dla Dockera. Zarówno Gradle, jak i Maven otrzymali wygodniejsze wsparcie tak zwanych buildpacków, pozwalających na bardzo wygodne tworzenie dockerowych obrazów. Dodatkowo, wprowadzono obsługę pakowania do kontenerów aplikacji w formacie *.war (ciekawe, jak dużo ludzi deployuje Spring Boota na Tomcat’cie ), od razu wprowadzając mechanizm pozwalający na minimalizację zmian między kolejnymi iteracjami obrazu, wcześniej dostępny dla formatu *.jar.

Oczywiście to nie wszystko.owy Spring to również klasyczne usprawnienia w kontekście observability, nowy sposób inicjalizacji DataSource’ów oraz podbicie większości springowych projektów (pokroju Spring Security – ostatnio wpadł nam w łapy fajny artykuł tłumaczący podstawy jego działania – czy Integration) do najnowszych wersji. Ogólnie zmian nie ma jakoś kosmicznie wiele, co pokazuje dojrzałość projektu, ale myślę że mimo to warto rozważyć, choćby ze względu na interesujące zmiany przynoszone przez ostatnią aktualizację Gradle.

Źródła

2. Kotlin Team opublikował nową Roadmapę

Niedawno świętowaliśmy premierę nowej wersji Kotlina, teraz zaś mamy okazję pokazać odświeżoną wersję jego Roadmapy. Wersja 1.5 pewnie zagościła już w projektach co poniektórych szczęśliwców, teraz czas przyglądnąć się, co nowego ma przynieść.

Z pewnością bardzo kluczowym z punktu widzenia jest fakt, że po stworzeniu w ramach wersji 1.5 nowej pośredniej reprezentacji kodu Javowego, przyszedł czas na skonsumowanie wygenerowanej w ten sposób wartości. Trwają pracę nad nowym kompilatorem, którego celem jest teraz szeroko pojęta optymalizacja. Mimo, że twórcy sugerują różnorodne usprawnienia (jednym z nich jest przykładowo znaczenie bardziej agresywne zrównoleglenie wykonanych zadań), to efektem wynikowym dla użytkownika końcowego jest nowa jakość, jeśli chodzi o szybkość całego procesu, która ma być w ten sposób uzyskana. Dodatkowe usprawnienia ma również dostać budowanie kotlinowych aplikacji z pomocą Gradle.

Jeśli chodzi o wydajność, to również w ramach IDE mają być poczynione znaczne poprawki – choć muszę przyznać, że pod tym względem nigdy nie odczuwałem znaczących problemów, to biorąc pod uwagę że w zasadzie cały czas Intellij jest w tyle, jeśli chodzi np. o kotlinowy autocomplete w porównaniu do Javy, to nie ma się chyba co dziwić, że chcą, aby ich klejnot koronny wypadł jak najlepiej. Sam kotlinowy plugin ma również trafić do monorepo razem z Intellij, co zgodnie z zapowiedzią przyspieszy pracę nad rozszerzeniem.

W planach jest też kilka ciekawych funkcjonalności w samym języku. Otóż jest to wprowadzenie wsparcia dla tak zwanych “wyczerpujących when’ów”. Ich rolą jest automatyczne wykrywanie sytuacji, gdy instrukcja typu switch nie wykorzysta wszystkich dostępnych wariantów np. konkretnego enuma, co pozwala wyłapać sytuacje, gdy rozszerzając enumeracje czy np. sealed classy zapomnimy zaktualizować kod o obsługę nowych wersji. Dużo serca też ma zostać poświęcone lepszej interoperacyjności javowych adnotacji.

Podobno również jednym z głównych celów w najbliższych miesiącach ma być zwiększenie konkurencyjności Kotlina podczas programowania backendowego. Jeżeli chodzi o biblioteki, to zapowiedziano pracę nad kotlinx.serialization w wersji 1.3 (niedawno informowaliśmy o wersji 1.2), oraz o kotlinx.coroutines w wersji 1.6 (w zeszłym tygodniu swoją premierę miała 1.5, stanowiący m.in. milowy krok na drodze do wsparcia Reactive Streams, wprowadzający poprawki do Channel API oraz ułatwiające pisanie testów za pomocą JUnita 5).

Programiści Kotlina po wprowadzeniu wsparcia Reactive Streams do Korutyn

Ale oczywiście Kotlin to nie tylko JVM, ale również warianty na różne inne platformy, gdzie również odbywają się pracę. Ciekawą zapowiedzianą nowością jest m.in. nowy format pośredni dla kodu javascriptowego. Kotlin Native ma otrzymać też wsparcie dla Apple Siliconu. Trwają także prace nad eksperymentalnym wsparciem WebAssembly, a dzielenie kodu między wersjami na platformy IOS i Android ma zostać znacznie polepszone.

PS: Podczas ostatniego Google I/O poinformowano, że Kotlin otrzymał nowe API do procesowania adnotacji, a nasz ulubiony Kotlin Jetpack Compose w wydaniu androidowym jest na najlepszej drodze do uzyskania stabilności. Ciekawe, na ile przełoży się to na rychłą premierę wersji desktopowej i webowej.

Źródła

3. Premiera Spock Framework 2.0

Mała rzecz, a cieszy. Spock jest chyba ostatnim powodem, dla którego ktokolwiek ma jeszcze w swoim projekcie Groovy’ego, ale jest to powód bardzo dobry. Spock pozostaje jedną z najwygodniejszych bibliotek służących do testowania javowych aplikacji, a jego edycja 2.0 przynosi masę, nieoczywistych na pierwszy rzut oka, zmian.

Zacznijmy od faktu, że o ile do tej pory Spock charakteryzował się pewną dozą kompatybilności z JUnitem (pod maską używał jego JUnit 4 Runner), to teraz jest on w pełni oparty o tak zwany JUnit TestEngine. Zmiana ta sprawia, że de facto Spock staje się “słodzikiem składniowym” nad JUnitem – co wbrew pozorom ma sporo zalet. Co to oznacza w praktyce? Wszędzie tam, gdzie wspierany jest JUnit (czyli na dobrą sprawę w ramach każdego narzędzia odpalającego Javę) możliwe będzie również natywne wsparcie Spocka. Zmniejszy to narzut społeczności związany z potrzebą rozwijania wielokrotnie tych samych mechanizmów.

Spock 2.0 to również wsparcie dla Groovy’ego w wersji 3.0 (którego to premiera obok JavyFX 15 była jednym z moich największych zaskoczeń 2020, jeśli chodzi o JVM). Z jednej strony jest to duże wsparcie tej umierającej platformy, z drugiej zaś kolejny krok w kierunku jej marginalizacji. Spock pozbył się bowiem w nowym wydaniu wszelkich opartych o nią zależności, za wyjątkiem gołego, bazowego groovy.jar.

Oczywiście, sporo zmian i usprawnień znaleźć można w samej składni, ale w tym kontekście odsyłam Was do pełnych Release Notes.

Źródła

Bonus: Premiera Helidon 2.3

Skoro tyle o premierach, nieco nieuczciwym byłoby nie wspomnieć również o nowej minorowej wersji Helidona, która to wypuszczona została w zeszłym tygodniu. Ten rozwijany przez Oracle framework oparty o Jakartę EE, wyraźnie mocno stawia na wygodę współpracy z innymi narzędziami, gdyż poprzednia edycja to głównie ogłoszenia tego typu. Dostajemy bowiem wygodniejsze wsparcie dla Oracle Cloud Infrastructure oraz natywną integrację z HashiCorp Vault oraz Neo4j. Z pewnością ważnym ogłoszeniem jest też wsparcie dla Micrometera, który stał się de facto branżowym standardem w wypadku serwerowych javowych aplikacji, cieszy więc fakt, że kolejny framework postanawia zapewnić wygodne wsparcie dla tego rozwiązania. Standaryzacja w kontekście metryk raczej przyniesie nam więcej pożytku niż szkody.

1. Wydano Spring Boot 2.5

Źródła

2. Kotlin Team opublikował nową Roadmapę

Źródła

3. Premiera Spock Framework 2.0

Źródła

Bonus: Premiera Helidon 2.3

Odkryj więcej świetnych treści!