JVM Tuesday vol. 72 – Java w 2022, Pisanie Bibliotek, Java System Logger

1. Co będzie się działo w Javie w tym roku?

W 2022 weszliśmy już pełną parą i zakończyliśmy chyba na dobrę czas podsumowywania 2021 – czas spojrzeć w przyszłość.

A ta maluje się interesująco, choć nie spodziewajcie się jakiejś wielkiej rewolucji. Nicolai Parlog przygotował bowiem w swoim wideo oraz artykule swoisty “Status Update” czterech najistotniejszych projektów Javowych – Valhalla, Panama, Loom i Amber. Uwielbiam tego typu sumaryzację, ponieważ czytając jeden tekst jesteśmy w stanie (choć dość pobieżnie) zorientować się w kierunku, w którym idzie JVM. Nicolai świetnie orientuje się też w planach twórców Javy, dlatego jest to też idealne miejsce, żeby dowiedzieć się np. co takiego zobaczymy w ramach Amber już po wprowadzeniu Pattern Matchingu. Dzięki temu rzeczywiście można mniej więcej przewidzieć, jakich zmian spodziewać się należy w przyszłym roku.

Dla mnie powyższe podsumowanie jest dosyć symptomatyczne, jeśli chodzi o ukazanie tempa rozwoju JVMa. Z jednej strony w ekosystemie dzieje się wiele (powyższa czwórka to absolutnie nie jedyne projekty w ramach JVM, żeby wspomnieć tutaj o wydanym jesienią Lanai), jednak od paru lat to właśnie powyższa czwórka to swoiste konie pociągowe całej platformy, które posuwają do przodu cały ekosystem. Ich wdrożenie to proces ciągły i podejrzewam, że zostaną z nami jeszcze przez parę lat, chociaż cieszy, że rok 2021 przyniósł już bardziej skonkretyzowane JEPy do takiej Valhalli i Looma. Śledząc jednak ich rozwój od paru lat (a konkretnie już od 2014 roku), jestem szalenie ciekawy tego, co wydarzy się, gdy “Wielka Czwórka” zostanie wdrożona i jak czy są już jakieś plany na Javę 2030.

Źródła

2. Jakie decyzje podejmują twórcy bibliotek w 2022?

Kiedyś to były czasy, teraz nie ma czasów.

Porozmawialiśmy sobie o wszystkich zmianach, jakich Java doczekać się ma jeszcze w roku 2022, ale nie zmienia to faktu, że mamy do czynienia z dość stabilnym ekosystemem programistycznym. Nie da się jednak ukryć, że kilka ostatnich lat tchnęło nieco “życia” w platformę, co jest na swój sposób ekscytujące dla programistów. Jednocześnie jednak okazuje się, że dla twórców bibliotek nowa sytuacja wprowadza pewne komplikacje.

Jakie? W dogłębny sposób (ze względu na szatę graficzną i styl, początkowo myślałem, że mamy do czynienia z postem @shipileva) przygląda się im w swoim artykule Michael Simons z neo4j, opisując proces decyzyjny stojący za powstaniem Neo4j-Migrations. Całość to frapująca lektura, ponieważ okazuje się, że w 2022 roku ilość mikro decyzji do podjęcia jest zaskakująco duża. Wychodząc poza standardowe dywagacje Maven vs Gradle, zastanowić się przykładowo trzeba, jaką minimalną wersję JVMa chcemy wspierać – decyzja ta implikuje również różne możliwe podejścia do JPMSa. Z tyłu głowy należy mieć również rosnącą popularność GraalVM, który rządzi się swoimi własnymi prawami, Całość wywodu jest bardzo klarowna, dlatego nawet jeśli nie jesteście twórcami bibliotek, i tak polecam lekturę – jest to unikalny materiał, w całości oparty o doświadczenia autora.

Źródło

Maintaining a medium-sized Java library in 2022 and beyond

3. Jak Java System Logger sprawdza się jako alternatywa dla log4j?

A na koniec – Log4Shell. Wiem, że wszyscy 🤮 tym tematem (ja również), dlatego o samej podatności będzie niewiele. Porozmawiamy sobie za to o tym, jak cała grudniowa “akcja” wpłynęła na społeczność i jej podejście do wszelakich loggerów. Pewnie ciężko jeszcze mówić tu o jakimś wielkim odwrocie, ale społeczność zaczęła poważnie przyglądać się alternatywom.

Okazuje się bowiem, że całkiem interesującą alternatywą dla wszelkiej maści bibliotek może być Java System Logger. To dostarczone wraz z Javą 9 nigdy nie zdobyło sobie jakiejś szerokiej popularności – programiści siłą rozpędu używali tego co znali, czyli wszelkich Log4J, SLF4J czy innych Logbacków. Nagle okazało się, że właściwie podobny efekt można uzyskać za pomocą znacznie mniej potężnego (ergo – posiadającego mniej przestrzeni na podatności) standardowego logowania javowego. Świetna analizę tematu znajdziecie tutaj.

Ciekawą reperkusją jest również proces patchowania bibliotek, które od dekady pozostawały bez wsparcia – widać, że nagle pojawiła się w firmach potrzeba, żeby lepiej przyglądać się własnym systemom do logowania. Przykładem tutaj może być choćby projekt reload4j, fork log4j jeszcze w wersji 1.2.17, której End-Of-Life nastąpił jeszcze w 2012 roku. Kto jest potencjalnym odbiorcom całości najlepiej obrazuje fakt, że o ile wspomniane w poprzedniej sekcji Neo4j-Migrations rozważało, czy nie porzucić Javy 1.8, reload4j będzie działał prawidłowo nawet w projektach napisanych w Javie 1.5.

Ogólnie jednak jest to trochę smutne, że Log4j stał się synonimem problemów z bezpieczeństwem i masa jadu wylała się w sieci na jego twórców. To właśnie oni byli bowiem cichymi bohaterami tamtych gorących grudniowych dni, pracującymi w pocie czoła nad podatnością zagrażającą całemu światu IT. Sytuację bardzo dobrze opisuje artykuł opublikowany przez Bloomberga. Trzeba przyznać, że choćby ten fakt pokazuje znaczenie ich pracy – nie wiem czy kiedykolwiek jakaś podatność bezpieczeństwa aż tak mocno przebiła się do mainstreamu – nie wiem, czy nawet Heartbleed albo Spectre nie zdobyły jednak mniejszej publiki.