Poprzedni tydzień był relatywnie wolny od dużych newsów, ale i tak mamy dla was dwie nowe wersje istotnych dla ekosystemu narzędzi oraz kolejne ogłoszenie w sprawie Eclipse Adoptium. Zapraszamy do lektury!
1. Gradle 7.0 wydane
Kawałeczek historii: kiedy wchodziłem w Javowy ekosystem niecałe dziesięć lat temu, właściwie sytuacja była dosyć prosta. Standardowym narzędziem do budowania projektów był Maven, potem długo, długo nic, a potem Ant (zwykle w archaicznych projektach, zwykle też odpalany przez Mavena). Gradle w tym okresie zaczął powoli przebijać się jako alternatywa dla tych, których krępuje mocno sztywny, deklaratywny sposób definiowania projektów przez POMy (dla tych którzy nie pamiętają, jest to akronim od Project Object Model). Żeby cokolwiek “customowego” zrobić w Mavenie, w zasadzie każdorazowo niezbędne było pisanie mrocznych MOJO.
Dla osób o tego typu potrzebach, elastyczny model orkiestracji oferowany przez Gradle, w połączeniu z możliwością “skryptowania” przy użyciu niezwykle popularnego swego czasu Groovego jawił się jako interesująca alternatywa. Jednak to moment to dopiero decyzja Google o uczynieniu Gradle domyślne rozwiązanie do budowania aplikacji androidowych zapewniło mu wiatr w skrzydła, i z regularnością karabinu maszynowego zaczęły ukazywać się (często paskudnie ze sobą niekompatybilne) nowe wydania. Przez lata Groovym stracił trochę animuszu, więc cały projekt powoli zaczął migrować w kierunku znacznie bardziej przyszłościowego Kotlina. Po drodzę przepisał się na niego min. Spring, co też było pewnym kamieniem milowym.
Tym sposobem dochodzimy do zeszłego tygodnia, gdzie ukazała się siódma wersja tego popularnego build toola (aczkolwiek należy pamiętać, że Maven ciągle jest popularniejszy, choć ta różnica nie jest już olbrzymia – jest używany przez 71% programistów, w porównaniu do 48% przy Gradle według State of Developer Ecosystem od JetBrains). Ze zmian które szczególnie wpłyną na Developer Experience, z pewnością należy wymienić tutaj dalsze ulepszanie inkrementalnych buildów. Udało się je przyspieszyć dzięki efektywniejszemu wykonywaniu zapytań I/O do systemu plików poprzez tak zwane file watchery.
Ustabilizowane zostało równie wsparcie dla modułów Jigsaw/JPMS (rychło w czas), aczkolwiek to już była raczej kwestia formalności – sam używałem Gradle dokładnie w tym celu przy okazji wydania 6. Zaprezentowano również wersje preview tak zwanego centralnego katalogu wersji (nowego sposobu na przechowywanie globalnych w skali projektu wersji konkretnych zależności). Dla tych którzy czasem gubią się w bardzo skomplikowanym gradlowym cyklu życia projektu, umożliwiono testowanie ulepszonego systemu walidacji plików konfiguracyjnych.
Z pewnością warto wymienić też fakt, że Gradle 7.0 może być odpalany przy użyciu JDK 16, natywnego wsparcia doczekały się też procesory M1.
Oczywiście, to nie wszystkie zmiany (nieco ciekawych nowych możliwości pojawiło się też w kontekście wspomnianego gradlowego matecznika, czyli Androida). Jeżeli jesteście zainteresowani, odsyłam do pełnych Release Notes.
Źródła:
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Wydano nową wersja JDK Mission Control
JDK Mission Control przez lata było znane tylko wąskiej grupie programistów JDK – nie wydarzyło się to bez powodu. To zbudowane w oparciu o IDE Eclipse, potężne narzędzie do debugowania problemów na poziomie maszyny wirtualnej, do niedawna było częścią komercyjnego wsparcia Javy oferowanego przez Oracle (a wcześniej przez Suna – Mission Control to naprawdę długo już rozwijane narzędzie).
Sytuacja jednak się zmieniła, a firma Larry’ego Ellisona postanowiła zacząć monetyzować Javę w nieco odmienny sposób, czyniąc cały Oracle JDK płatnym produktem. Miało to jednak swoje pozytywne aspekty, a jednym z nich było min. otwarcie źródeł Mission Control oraz Flight Recordera (którego można traktować jako zaawansowane narzędzie do zrzutów pamięci). Dzięki temu, wreszcie trafiła ona do rąk rzeszy programistów, którzy zamiast lizać cukierka przez papierek i słuchać jaki to on nie jest słodki, mogli położyć na narzędziu swoje ręce i wypróbować je w akcji. Teraz zaś ukazuje się nowa edycja narzędzia, oznaczona numerem wersji 8.
Twórcy chwalą się co prawda ponad dwustoma poprawkami i ulepszeniami, ale spośród tego nich z pewnością wybija się nowy “flame graph”. Java Mission Control pozwala Ci zapiąć się na dowolny z uruchomionych na danej maszynie wirtualnej Javowych procesów i podglądnąć zużyte przez nie zasoby. Ulepszony Flame Graph ma dawać możliwość wygodniejszego obserwowanie, które obiekty powodują wzmożone użycie pamięci w aplikacji.
Z mojej perspektywy jeszcze ciekawszym jest nowy widok grafu metod oraz tak zwany widok predecesorów i sukcesorów. Dzięki niemu będziemy mogli lepiej połapać się, jak poszczególne metody w aplikacji są wywoływane i w jakiej kolejności. Dzięki temu ładniej będzie nam analizować zrealizowane przez Flight Recorder zrzuty stanu aplikacji.
Wprawdzie mówi się, że w dobie systemów rozproszonych i chmury wszystko powinno wrzucać się do centralnego rejestru metryk, ale jeżeli mamy problem z gatunku tych związanych z pamięcią albo przepływami w informacji, warto dać Java Mission Control szanse. Udostępnione w niej narzędzia mogą zaoszczędzić nam godzin łamania sobie głowy nad nietrywialnymi problemami np. z pamięcią.
Źródła:
3. IBM zostaje członkiem Eclipse Adoptium Working Group
A na koniec mały news. Dwie edycje temu pisaliśmy o tym, że AdoptOpenJDK przeszło pod skrzydła Eclipse i zostało przechrzczone na Adoptium. Teraz do członków założycieli fundacji dołącza również IBM.
Nie jest to z pewnością wielkie zaskoczenie – IBM od dawna był mocno zaangażowany w społeczność AdoptOpenJDK, udostępniając nie tylko komercyjne wsparcie dla całego projektu (oczywiście za pieniążki, ale w oczach wielu firm na pewno wyniosło to AdoptOpenJDK do roli realnej alternatywy dla Oracle JDK), ale też infrastrukturę umożliwiającą testowanie i rozwijanie projektu AdoptOpenJDK. Należy bowiem pamiętać, że JDK to oprogramowanie jak każde inne i wymaga też np. platformy Continuous Integration. Dużą kontrybucją IBMu jest również oddanie fundacji Eclipse kodu źródłowego OpenJ9 – alternatywnej, ale w pełni kompatybilnej ze specyfikacją implementacji JVMa, która posiada kilka interesujących cech, jak np. szybszy start aplikacji.
Adoptium rozwija się więc dynamicznie, a w projekt zaangażowane jest coraz więcej podmiotów przygotowujących swoje własne, skrojone pod “wysublimowane” gusta wersje JDK. Jak widać więc, przejście pod skrzydła Fundacji Eclipse już zaczęło procentować.