JVM Wednesday vol.92 – Classfile API, zalety Kotlina, migracja do Javy 11 w LinkedIn

1. Classfile API – Natywne API do generowania klas trafi do Javy

Nawet w takie spokojniejsze tygodnie jak ten, na Briana Goetza zawsze można liczyć. Opublikował on bowiem, zupełnie znienacka, bardzo interesującego JEPa, znajdującego się w tematyce która w bardzo małym stopniu zahacza o te najbardziej “wokalne” kwestie, o których dyskutuje się ostatnio w ramach JVMa. Draft Classfile API sam w sobie nie wywróci życia programistom “przemysłowym”, ale twórcy bibliotek dostaną kolejne mały, przydatny dodatek do biblioteki standardowej, pozwalający im na zminimalizowanie zależności.

Cytując tutaj samego JEPa – bardzo wiele “javowych” narzędzi opiera się na generowaniu klas – na tym polega ta cała legendarna magia wielu narzędzi. 

Do tej pory niezbędne było do tego używanie zewnętrznych bibliotek. Twórcy JDK zdecydowali jednak cały proces ułatwić, proponując stworzenie wydajnego API do odczytu, zapisu i przekształcania plików klas. Zaletą narzędzia, nie tak oczywistą na pierwszy rzut oka, ma być gwarancja zgodności z całości z aktualną wersją Javy i potencjalnymi zmianami. Brian Goetz zarzeka się w proposalu, że celem twórców nie jest zastąpienie istniejących bibliotek, a po prostu wyjście na przeciw tym, którzy nie chcą się zastanawiać, która wersja ByteBuddy’ego będzie odpowiednia.

To oczywiście nie tak, że Java nie posiada żadnego sposobu na manipulowanie klasami. Jak ładnie wytłuszcza nowy proposal, w “bebechach” JVMa znajduje się biblioteka ASM (jdk.internal.org.objectweb.asm.ClassReader) , która używana jest między innymi przez klasy związane z Lambdami. Wiąże się z tym interesujący problem “jajka i kury” – jako, że aby sfinalizować wersje JDK, kod Javy musi być stabilny, znajdujący się w internalach javy ASM (będący biblioteką) zawsze pozostaje krok do tyłu w stosunku do głównej edycji Javy.  Takich “pomniejszych” bibliotek jak Xalan czy cglib jest w JDK sporo, i nowe API ma wyczyścić internale projektu min. konsolidując te właśnie 

Dlaczego teraz? Twórcy przekonują, że ewolucja JVMa znacznie przyspieszyła i coraz więcej zmian odbywa się właśnie na poziomie generowanego kodu. Dzięki nowemu API duże inicjatywy jak np. Valhalla ma być mniej uciążliwe dla całego ekosystemu. 

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Co tak naprawdę boli programistów Kotlina po powrocie do Javy?

Drugi z dzisiejszych tekstów to w zasadzie “drobnica” i nic co mocno wstrząśnie waszym życiem, ale jest na tyle przystępny w lekturze, że stwierdziłem iż warto się z Wami nim podzielić. Nicolas Fränkel, który w ciągu życia naszego newslettera nieraz się przez niego przewija, opublikował ostatnio swoje przemyślenia o wszystkim tym co tracimy, kiedy z Kotlina jesteśmy zmuszeni wracać do Javy.

Tekst sam w sobie nie jest czymś wyjątkowym (takich, a nawet dużo bardziej dogłębnych porównań, w sieci nie brakuje), ale na jego korzyść przemawia zwięzłość oraz lekkość pióra Nicolasa. Całość można przejść w dosłownie parę minut, a autor skupia się na prawdziwym “Developer Experience” – tych funkcjonalnościach, których realnie jest mu brak za każdym razem gdy siada do Javy. I muszę przyznać, że ten krótki wywód o tak oklepanych tematach jak generyki i nulle moim zdaniem daje nam w przystępny sposób amunicję, pozwalającą na przekonanie kogoś do dania Kotlinowi szansy. W mojej banieczce zawsze tą funkcjonalnością, która zachęcała ludzi do migracji były Korutyny, ale biorąc pod uwagę jak niewiele ludzi pisze realnie współbieżny kod, bez zrzucania tego na adnotacje @Asynchronous, to właśnie mniejsza ilość błędów dzięki niemutowalności czy możliwość obejścia upośledzonych javowych generyków może być znacznie lepszym argumentem. 

Zatem jeśli chcecie przekonać kogoś, żeby jednak zdecydował się dać szansę ketchupowemu językowi (albo samemu nad tym się zastanawiacie), myślę, że warto z publikacją Nicolasa się zapoznać.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Jak wyglądała migracja do Javy 11 w takiej firmie jak LinkedIn?

Mówi się dużo o tym, że im większa firma, tym bardziej ociągają się z tym, żeby wprowadzić nowe wersje oprogramowania na produkcję. Dodatkowo, sporo osób twierdzi, że tak naprawdę ósemka jest “good enough” – w znaczeniu, że wszelkie zmiany, które zostały wprowadzone od JDK 9+ okazują się być na tyle małe, że cały wysiłek związany z migracją po prostu nie raz nie jest warty. Nie ma się jednak co dziwić – w dużych firmach proces migracji nie zawsze jest bezbolesny. Dlatego też zawsze ciekawie przeczytać analizy, jak taki proces odbywa się w innych firmach. Mało komu chce się pisać o tak “trywialnych” rzeczach jak migracja Javy, dlatego (podobnie jak w przypadku zalet Kotlina) wykorzystuje okazję, żeby podrzucić taką “oczywistość”, która w praktyce wcale aż tak oczywista nie jest.

Tekst LinkedIna jest zaskakująco ciekawy, ponieważ skupia się na mocno “życiowych” fragmentach całego procesu migracji. Dowiecie się z niego sporo o usprawnieniach, jakie przynosi nowa Java – zwłaszcza o Garbage Collectorach, które mogły umknąć trochę Waszej uwadze w wyniku tego, jak bardzo “iteracyjnym” był proces wprowadzania do nich poprawek na przełomie kilku ostatnich wersji. Sporo miejsca poświęcono też mniej oczywistym problemom, jak choćby fakt że niektóre API JavaEE rozpanoszyły się w wielu dużych codebase. Z mojej perspektywy najciekawszym był jednak poruszony aspekt tego jak trudnym w utrzymaniu jest drzewo zależności posiadających różne warianty JDK, zwłaszcza te pochodzące ze świata przed i po wprowadzeniu modułów. Podobnie jak w przypadku powyższego tekstu o Kotlinie, całość okazała się być znacznie bardziej interesująca niż kazał się spodziewać tytuł.

Polecam, w końcu jest to ta unikalna możliwość, że w nikim nie wzbudzi zaniepokojenie fakt, że w godzinach pracy czytacie LinkedIna.

A jaki jest dla Was dobry powód do przepisania się na nową Javę? Dla kolegi pytam 😅