JVM Monday vol. 20

1. Gradle 6.8 wydane

Na rozgrzewkę – szybki newsik.

Gradle 6.8 zostało wydane i przynosi parę interesujących zmian. Użytkowników Kotlinowej wersji DSL z pewnością ucieszą się, że zarówno czas kompilacji, jak i zasobożerność tej odmiany Gradle znaczenie spadły. Dodatkowo, build-tool nauczył się rozróżniać różne “smaki” Javy, i można teraz zdefiniować, jakiego vendora chce się używać – może być to przydatne w sytuacji, gdy używamy którejś unikalnej funkcjonalności dostępnej tylko w konkretnym JDK – przykładem niech będzie tutaj Wisp (alternatywna implementacja korutyn) dostępna wyłącznia w Dragonwell JDK od Alibaby.

Pojawiają się też poprawki dotyczące bezpieczeństw (wyłączenie domyślnego wsparcia dla TLS 1.0 i 1.1). Lepsze zarządzanie zależnościami i dalsze działanie w kierunku dających się używać “Composite builds” – elastycznego klejenia modułów w jeden, skrojony na miarę projekt, co może się przydać w wypadku tworzenia aplikacji w różnych wariantach z mniejszych kawałków (miałem takie coś w poprzednim projekcie na produkcji).

No i oczywiście “wincyj cache”. W zasadzie każda nowa wersja Gradle to dalsze poprawki dla cache.

PS: Ostatnio Bruce Eckel, którego możecie kojarzyć jako twórcę legendarnego już “Thinking in Java” (moja pierwsza książka o Javie ♥️ – dzisiaj niestety już nie polecam, bo się mocno zestarzała ) opublikował opinie (https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/) o Gradle oraz jego programistycznym modelu. Bardzo interesująca rzecz.

2. Jaka była rola JetBrains w ataku na SolarWind?

No i znowu mamy polityczną dramę, tym razem z JetBrains w tle. Miała ona kilka faz, przewinęła się również szeroko przez wszelkiej maści programistyczne społeczności. Teraz, gdy kurz trochę opadł, czas wyjaśnić: Czy JetBrains to rzeczywiście są rosyjscy hakerzy i powinniśmy odinstalować ich oprogramowanie?

Zaraz przed świętami Bożego Narodzenia na jaw wyszedł fakt, że oprogramowanie SolarWind, używane przez organizacje rządowe USA, zostało zaatakowane. Atak został wykryty przez Microsoft, a jego zakres dotyczyć miał ponad 250 agencji rządowych. Hack wysublimowany i bardzo interesujący (szczegóły ataku możecie znaleźć tutaj: https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/), ale pewnie jego temat nie wróciłby na początku tego roku (a przynajmniej poza kręgami CyberSecurity), gdyby nie wciągnięcie w całą sprawę JetBrains.

Otóż na początku poprzedniego tygodnia na łamach New York Times’a pojawił się artykuł (https://www.nytimes.com/2021/01/06/us/politics/russia-cyber-harck.html) jakoby głównym wektorem ataku było oprogramowanie TeamCity o JetBrains. Mimo że całość używa nieco mało precyzyjnej terminologii i w dość alarmistycznym tonie ostrzega, że firma została założona przez dwójkę Rosjan, to jednak nie jest to tekst zlepiony przez stażystów, a grupę doświadczonych redaktorów, którzy już wcześniej opisywali m.in. cyberataki ze strony Iranu.

Na odpowiedź JetBrains nie trzeba było długo czekać – opublikowali oni dwa stanowiska (https://blog.jetbrains.com/blog/2021/01/06/statement-on-the-story-from-the-new-york-times-regarding-jetbrains-and-solarwinds/ oraz https://blog.jetbrains.com/blog/2021/01/07/an-update-on-solarwinds/) w którym przyznają, że według ich wiedzy atak rzeczywiście nastąpił poprzez systemy budowania aplikacji, a SolarWind używał ich oprogramowania (tak jak wiele firm), ale nie ma żadnych dowodów jakoby problem istniał w samej aplikacji. Jeżeli nawet TeamCity było furtką, to sugerują, że przyczyną podatności mogła być zła konfiguracja środowiska.

Sprawa nabiera rumieńców i jeszcze do niej pewnie wrócimy, aczkolwiek na ten moment ciągle pozostałbym przy twierdzeniu, że nie ma co odinstalowywać Intellija z komputera.

3. Weryfikacja obietnic Project Loom wywołuje zażarte dyskusje

Na koniec mięsko, które mnie osobiście pochłonęło na dobre ~3h, ale też rzadko zdarzają się posty które do publicznej dyskusji ściągają osoby tworzące na co dzień JVM.

Otóż Greg Wilkins (Project Lead znanego wszystkim Jetty’ego) postanowił przygotować testy Early Access buildu Projektu Loom, w celu zweryfikowania, na ile obietnice jego twórców mają odzwierciedlenie w realiach. Na pierwszy ogień poszła możliwości stworzenia miliona równocześnie istniejących równoległych wątków. Efekt jest hmmm… połowiczny. Pisząc w skrócie, nie ma problemu ze stworzeniem wątków jako takich, ale za wiele to się w nich nie zrobi – nawet średniej wielkości Stacktrace (1000 operacji) per wątek szybko udowadnia, że RAM nie jest z gumy. Także o ile rzeczywiście istnieje możliwość stworzenia miliona wątków, to styl programistyczny w nich użyty musi być drastycznie inny (np. poprzez mocne ograniczenie bibliotek zewnętrznych, które potrafią bardzo stacktrace wydłużać).

Potem pojawiła się kontynuacja posta, tym razem biorąc na warsztat już bardzo konkretny przykład: uproszczony model chatu tekstowego dla użytkowników gry online. Z tej próby Loom wychodzi zwycięsko – kosztem nieco większego zużycia procesora i innego charakteru konsumpcji pamięci (tworzenie dużej ilości krótko żyjących obiektów) udało się zastąpić rozwiązanie oparte na Async API.

Ze względu na mocno krytyczny charakter pierwszego posta, pojawiła się do niego masa komentarzy, zarówno na Reddicie (gdzie Ron Pressler odpierał zarzuty) jak i na liście mailngowej OpenJDK, gdzie znowu cały temat komentował Alan Bateman. Cała dyskusja jest równie frapująca jak wspomniane artykuły.

Po przewertowaniu zarówno artykułów jak i całości dyskusji, moja osobista konkluzja – Loom ma potencjał, ale powinien popracować nad marketingiem i przestać drażnić społeczność rzucaniem liczb z kosmosu .

BTW: Wraz z Loom wprowadzone zostanie API do zrzucania StackTrace jako JSON – jeśli to nie jest dobry powód do kontynuacji tego projektu, to nie wiem co jest.

1. Gradle 6.8 wydane

2. Jaka była rola JetBrains w ataku na SolarWind?

3. Weryfikacja obietnic Project Loom wywołuje zażarte dyskusje

Odkryj więcej świetnych treści!