JVM Weekly #96 - Microsoft inwestuje w Jakarte EE (tak, nie pomyliliśmy się)

1. Microsoft inwestuje w Jakarte EE (tak, nie pomyliliśmy się)

Są czasem takie nagłówki, po których przeczytaniu muszę je zrobić to jeszcze raz, żeby się upewnić że wszystko dobrze zrozumiałem. W pierwszej chwili informacja, że Microsoft staje się częścią ciała standaryzującego zarówno Jakarty, jak i MicroProfilu wydała mi się być po prostu… jakaś nierealistyczna.

Aczkolwiek akurat Microsoft lubi takimi rzeczami zaskakiwać. Do tej pory pamiętam moje oczy, gdy to właśnie oni wypuścili wersję Javy na procesory M1 🙀

To, że Microsoft ostatnimi czasy znacznie mocniej inwestuje w swoje wsparcie Javy, nie jest dla nikogo wielką nowością. Stopniowo macki (ale raczej w pozytywnym tego słowa znaczeniu) firmy z Redmond przenikają do coraz większej ilości organizacji i fundacji wkoło Javy, by wymienić tu choćby grupę roboczą Eclipse Temurin czy Java Community Process. Jednak Jakarta EE to po prostu trochę inna „liga”. O ile dotychczasowe działania nakierowane były głównie na możliwość wpływania na Javę jako platformę, Jakarta EE to już bardzo konkretny zestaw rozwiązań, a jego ciało standaryzujące składa się głównie z twórców serwerów aplikacyjnych. Microsoft stał się jedynym z dużych dostawców chmurowych (nie liczę w tym gronie Oracle) bezpośrednio zaangażowanych w rozwój korporacyjnej Javy.

Jak widać, dobrze „wygrzaną” technologią też nie pogardzi

I to właśnie w tym ostatnim kryje się klucz do rozwiązania powyższej zagadki. Azure będzie pierwszą chmurą, która zapewni natywne usługi serwerów aplikacyjnych Javy. Już dzisiaj dostępne zostaną zarówno WebLogic, jak i WebSphere czy JBoss EAP. Microsoft wydał również garść poradników, jak przeprowadzić proces takiej migracji do ich chmury. Trzeba przyznać, że jest to bardzo interesujący ruch i próba bezpośredniej konkurencji nie z Google i Amazonem, ale Oracle i RedHatem. Wychodzi to również naprzeciw potrzeb dużych klientów korporacyjnych, a to właśnie Ci stanowią gro użytkowników Azure.

Całość nowych możliwości prezentuje się jak na powyższym.

Żeby jednak nie było, że całość skupi się tylko i wyłącznie na Legacy aplikacjach – Microsoft zapowiedział, że również Helidon, Quarkus czy Payara Micro staną się „pierwszej klasy obywatelami” w ramach ich platformy. Całość ma być łatwa w releasowaniu dzięki udostępnionemu pluginowi do Mavena. Przykład przeprowadzenia procesu do np. Quarkusa znaleźć możecie tutaj. Wygląda to całkiem przyjemnie.

Zobaczymy jak będzie po wyjściu poza Hello World.

Źródła

2. Nowe podejście do inkrementalnej kompilacji Kotlina

Mimo bycia dość mało pasjonującym wydaniem, Kotlin 1.7 wprowadził do języka kilka interesujących dodatków. Jednym z nich jest usprawnienie inkrementalnej kompilacji. Temat tego, jak długim w wypadku Kotlina jest proces budowania aplikacji przewija się przez społeczność języka (i te przeglądy) od lat, a twórcy też nieustannie w nim dłubią. Właściwie, co duża edycja języka, to pojawiają się różnego rodzaju zapowiedzi w tym zakresie. Wynika to jednak z tego, że Kotlin jest jako język dość potężny, a przez to również skomplikowany. Stąd standardowe podejścia optymalizacyjne, które sprawdzają się w Javie, tutaj nie do końca spełnią swoją rolę.

Standardowa scena z życia Kotlin Developera

Dlaczego? To dość dobrze wyjaśnia nowa publikacja JetBrainsów o klarownym tytule A New Approach to Incremental Compilation in Kotlin. Jeśli miałbym go do czegoś porównać, to mówimy tutaj o czymś przypominającym standardowy Architecture Decision Record, ale w formie bardziej zjadliwej dla szerokiej publiki. Mamy tutaj więc do czynienia z przedstawieniem wyzwań architektonicznych oraz różnic w stosunku do standardowej Javy i wyjaśnienie, dlaczego w wypadku Kotlina kwestia cache kompilacji jest o wiele bardziej skomplikowana (spoiler: bogatszy Application Binary Interface (ABI)). Wymusza to na porzucenie standardowych mechanizmów dostarczanych przez Gradle i sporo sprytnej inżynierii od twórców języka.

Jeżeli interesowała Was kiedykolwiek teoria kompilatorów, artykuł od JetBrains zapewni Wam trochę jej „stosowanego” wariantu.

Źródła

A New Approach to Incremental Compilation in Kotlin.

3. Log4Shell zostanie z nami na dłużej 🙁

A na koniec mały powrót do przeszłości. Pamiętacie jeszcze apokalipsę, którą było wykrycie podatności w popularnej bibliotece log4j? Grudzień spłynął krwią, a raczej programiści zalali się kofeiną z powodu nadgodzin i czymś mocniejszym po pracy na odreagowanie stresów aktualizacji aplikacji, w tym czasem tych mocno przedpotopowych. Na szczęście problem mamy już z głowy i możemy już o nim zapomnieć, prawda?

Odpowiedź na to pytanie już pewnie znacie

Niestety nie. Cyber Safety Review Board, ciało doradzające prezydentowi Stanów Zjednoczonych dokonało analizy sytuacji i stwierdziło, że o ile na ten moment nie wykryto jeszcze żadnego dużego ataku wykorzystującego podatność Log4j, to jest to kwestią czasu. Wielka akcja aktualizacyjna zwiększyła co prawda czujność i opóźniła pierwszą fazę exploitowania biblioteki, ale na świecie w dalszym ciągu pozostaje ogromna ilość niezaktualizowanych aplikacji i serwerów, a ciągle dostępne w Maven Central podatne wersje każdego tygodnia są ściągane więcej niż 100 000 razy. Dodatkowo, o ile sprawa była głośna, nie wszystkie organizacje zadbały np. o odpowiednie prześledzenie używanych wersji bibliotek i aplikacji zewnętrznych, skupiając się na podbiciu Log4j we własnym kodzie.

Czekamy zatem, kto będzie pierwszą prawdziwą ofiarą Log4Shell. Na pewno łatwiej wskazać zwycięzców całej sytuacji – są to korporacyjne działy security, które dostały bardzo mocny oręż do ręki jeśli chodzi o nie używanie zależności zewnętrznych.