Ciekawi jaki Ślad Węglowy ma Wasza aplikacja? Jest narzędzie, aby to zmierzyć - JVM Weekly vol. 125

1. Jaki Ślad Węglowy ma Wasza aplikacja? Jest narzędzie, aby to zmierzyć.

Lubię słuchać podcastu airhacks.fm Adama Biena, stał się częścią mojego porannego rytuału podczas porannego odwożenia córki do żłobka. Styl luźnej dyskusji ma to do siebie, że pozwala gościom na podzielenie się sporą ilością luźnych przemyśleń, na które pewnie nie byłoby miejsca w innym formacie niż podcastowe „gadające głowy”. Jako przykład rzucić mogę odcinek z października zeszłego roku, w którym przy okazji dyskusji o CRaC i Serverless Adam zasugerował, że komunikat „redukcja śladu węglowego” bywa lepszym komunikatem dla biznesu niż nieco oklepane „zwiększenie efektywności”. W pierwszej chwili było nieco zaskakujące, ale gdy przypomnę sobie wysyp korporacyjnych komunikatów o planowanej „zeroemisyjności”, ma to głęboki sens i dla takiego serverlessa może rzeczywiście być przekonującą strategią sprzedażową.

Chyba, że biorąc pod uwagę sytuacje w branży powyższa narracja się wywróci z rowerka.

Skąd w ogóle przypomniał mi się cytat z podcastu z 2022? Ponieważ w zeszłym tygodniu premierę miał JoularJX 2.0. Czym jest JoularJX? To agent JVM służący do monitorowania zużycia energii na poziomie kodu źródłowego, które pozwala programistom monitorować i analizować zużycie energii przez aplikacje na różnych urządzeniach komputerowych i systemach operacyjnych. Jego modele umożliwiają oszacowanie zużycia energii przez komponenty sprzętowe, takie jak procesor i pamięć, a także zapewnia szczegółowe raporty i wizualizacje. A to wszystko, aby pomóc programistom zidentyfikować miejsca w ich oprogramowaniu i zoptymalizować jego efektywność energetyczną.

I w tym momencie programiści dołączają do powyższego kółeczka. Już mam w głowie nową fitness function dla architektury.

JoularJX 2.0 wprowadza nową funkcję, która pozwala śledzić moc i zużycie energii w na poziomie poszczególnych metod, zapewniając dokładniejszy wgląd w efektywność energetyczną oprogramowania. Wydanie zmniejsza też narzut powodowany przez samego JoularJX (trochę przykro by było, jakby z powodu tego całego raportowania doszłoby do znacznego zużycia energii, prawda?).

Trochę czego to ludzie nie wymyślą, a trochę jednak:

Źródła

2. Wydano Gradle 8.0

Początkiem tygodnia pojawiła się nowe wydanie Gradle – już 8.0.

Sporo usprawnień doczekał się Kotlin DSL, alternatywną składnią do tradycyjnego (i popularniejszego, o czym za chwilę) Groovy DSL, zapewniając lepsze podpowiadania składni przy edycji. Wraz z Gradle 8.0 poprawiona zostala kompilacji skryptów poprzez wprowadzenie interpretera dla deklaratywnych bloków pluginów {} w skryptach .gradle.kts, co daje zysk rzędu 20%, zbliżając czas procesowania Kotlin DSL do Gradle DSL. Gradle 8.0 aktualizuje również wersje Kotlin API do najnowszego 1.8 oraz umożliwia korzystanie z bibliotek Java 11 i funkcji językowych w skryptach kompilacji. Niestety, nie dotyczy to prekompilowane wtyczek, tylko samych gradle.kts.

Super, że twórcy dbają o to, żeby wsparcie dla Kotlina było jak najlepsze, ale przyznam, że mimo iż usilnie staram się używać właśnie wariantu w tym języku, to jednak mimo lat jest to strasznie niewygodne. Nie jest to winą samego Gradle – oni robią co mogą, ale dla społeczności jest bardzo niewygodnie tworzyć każdy przykład w dwóch wariantach, dlatego zwykle wszelkiej maści blog posty zawierają tylko wariant w Groovym. I o ile takie Maven Repository już się nauczyło prezentować również wariant Kotlinowy, to sam dzisiaj trafiłem choćby na stronę Lomboka, gdzie przy opisie konfiguracji dla Gradle takowego już nie uświadczymy. A im bardziej nietrywialny przypadek (a w Gradle da się tworzyć naprawdę skomplikowane twory), tym mentalna z jednego formatu na drugi jest trudniejsza.

Przy czym tak jak pisze, sam gradle.kts nie jest wiele winien.

Najnowsze wydanie Gradle wprowadza też usprawnienia dla dodatkowych lokacji kodu, przekazywanych przez parametr buildSrc, które teraz mają lepiej wspierać inkrementalną kompilację i buforowania zadań, a także łatwiejsze ich wsparcie z poziomu linii komend. Gradle nie uruchamia też już automatycznie testów dla buildSrc i jego podprojektów gdy nie są one potrzebne.

Po więcej szczegółów, a także dodatkowe zmiany w wersji 8.0 odsyłam do Release Notes.

Ostatnim (chyba ciekawszym niż same zmiany z nim przychodzące) aspektem nowego wydania jest podbicie dużej numeracji, co jak łatwo się domyśleć wynika ze złamania kompatybilności wstecznej z niektórymi aspektami gałęzią 7.x. W związku z tym pojawiło się trochę krytyki, że od czego jak czego, ale od build toola większość użytkowników wymaga stabilności i kompatybilności. Rozumiem takowe zarzuty, aczkolwiek akurat pod tym względem Gradle wykonał tytaniczną pracę w stosunku do tego, jak bardzo problematycznymi były upgrade jeszcze parę lat temu. Kiedy programowałem na Androidzie, każdorazowa aktualizacja buildów Gradle (dodatkowo wymuszana przez niekompatybilność starych wydań z nowymi wersjami pluginu Android SDK) była traumatycznym procesem. Dziś (przynajmniej w wypadku aplikacji serwerowych) jest pod tym względem znacznie lepiej.

A jak już przy build toolach jesteśmy, to podzielę się z Wami na koniec moim chyba ulubionym rozdziałem z książki Software Engineering at Google – Build Systems and Build Philosophy. Na przykładzie Bazela pokazuje on zupełnie drugą stronę medalu w stosunku do niezwykle elastycznego Gradle. Uzmysławia, jakie zalety i wady mają te dwie różne filozofie procesu budowania aplikacji.

Źródła

Bonus: Null Safety – Java vs Kotlin

Na koniec, trochę w formie bonusu, mam dla Was publikację dobrze korespondującą z głównym tematem poprzedniej edycji – próbom usprawnienia konceptu nullowalności przez projekt Valhalla.

Zasugerowałem tam, że być może wariantem, na który zdecydują się twórcy JDK będzie wprowadzenie jakiejś nowej adnotacji. Pomysł ten okazał się być nieco niefortunny, bo dosłownie dzień wcześniej Brian Goetz, Architekt Javy, wysłał maila, w którym dość jasno daje znać, że sam język powinien być wolny od adnotacji, a @Override w formie, w której był wprowadzony, nie był najlepszym pomysłem. Koncepcja ta więc raczej nie będzie miała miejsca, mimo, że wydaje się być bardzo naturalna. W końcu nie bez powodu mamy przez lata do czynienia z wysypem różnorakich wariantów @NonNull – widać jest potrzeba.

Nicolas Fränkel w zeszłym tygodniu opublikował tekst Null safety: Kotlin vs. Java, w którym pokusił się na porównanie czym różnią się podejścia do konceptu Nulla w obu językach. Jako jeden z elementów analizy podsumowuje on istniejące na rynku adnotacje i wymienia osiem różnych wariantów, posiadających różne pakiety oraz (co nawet gorsze) nieco odmienne zachowanie.

Już wiecie po co mi był wspomniany wyżej Lombok. Z tym sobie poradź, Google Copilot!

Patrząc na powyższe, warto przytoczyć (wspominaną też w artykule Nicolasa) inicjatywę jSpecify. Biorące w niej udział podmioty pracują nad zdefiniowaniem ustandaryzowanego zestawu adnotacji służących do analizy statycznej, a za pierwszy cel obrali sobie właśni @NonNulla (patrząc na powyższe – bardzo słusznie). Przewodzi jej Google, a biorą w niej udział tacy gracze jak choćby VMWare, Microsoft czy JetBrains, a więc twórcy wielu z powyższych adnotacji, mają więc oni moc sprawczą, aby posprzątać ten cały bałagan. Trzymajmy za nich kciuki.

Źródła

PS: W tym tygodniu wydanie poszło w środę, zamiast tradycyjnego ostatnio czwartku, bo mam 15.02.2023 i 16.02.2022 dwa wystąpienia na lokalnych JUG-ach z moim talkiem JVM Iceberg… we need to go deeper.

👉 W Środę (15.02) na Lublin Java User Group (LJUG).

👉 W Czwartek (16.02) na Polish Java User Group (PJUG) w Krakowie.

Jakby ktoś chciał wpaść zbić sobie piątkę – zapraszam 😄