JVM Tuesday vol. 41

1. Nie znudził się Wam jeszcze JEP-411? Bo temat nie chce zdechnąć

W ostatnich tygodniach świat Javy dość mocno żył JEP 411, który to proposal jak mało który wzbudził emocje w naszej dość spokojnej społeczności (dość powiedzieć, że to jest trzeci raz, kiedy wspominamy o tym JEPie w ramach naszego przeglądu). Wynika to pewnie z tego, że cała afera dotyka mocno filozoficznego aspektu naszej branży – potrzeba bezpieczeństwa styka się tutaj niejako z ekonomią, jeśli tak rozumieć można chęć uzyskania łatwiejszego w rozwoju i utrzymaniu, a więc elastyczniejszego i “tańszego” kodu. Sam JEP, mimo kontrowersji, po drobnych poprawkach zapowiedziany już został jako część JDK 17, ale cała afera ma ciekawy efekt – ten mało kogo interesujący temat przeniknął do szerokiej świadomości, czego efektem są publikacje od foojay.io.

W opublikowanych na platformie tekstach możemy dowiedzieć się naprawdę wiele na temat tego, jak tak naprawdę złożonym tematem jest bezpieczeństwo takiej platformy jak JVM. Pierwszy z tekstów, autorstwa Petera Firmstone’a, porusza temat tak zwanej “Zasady najmniejszych przywilejów” (The Principle of Least Privilege). Za tą donośnie brzmiącą nazwą tak naprawdę kryje się prosta, zdroworozsądkowa zasada mówiąca, że użytkownicy i kod muszą mieć dostęp tylko do zasobów i informacji wymaganych do wykonywania zamierzonych zadań. Autor tłumaczy w artykule, że pozbywając się SecurityManagera, twórcy JDK niejako zmuszają twórców programów do uruchamiania swoich aplikacji z pełnymi uprawnieniami procesu javowego, co w wielu przypadkach jest dramatycznie wręcz nadmiarowe.

Drugą, chyba jeszcze ciekawszą publikacją jest tekst tego samego twórcy, gdzie ten skupia się na próbie wytłumaczenia zawiłości związanych z różnymi warstwami bezpieczeństwa, do których dostęp mają programiści Java, i czemu SecurityManager stanowił tak kluczowy element tej układanki. “Pryncypium najmniejszego przywileju” oczywiście również się przez niego przewija, ale poza nim mamy okazję dowiedzieć się, jak bardzo zmiany przynoszone przez JEP 411 wpłyną na filozofię bezpieczeństwa całej platformy. Interesująca “pasza dla umysłu”.

Źródła:

2. Tonight, we dine in Valhalla – jak już dzisiaj przygotować swój codebase

Jest coś interesującego w sposobie, w jaki dostarczane są kolejne etapy projektów Loom, Amber i Valhalla. Java staje się wielkim eksperymentem, jeśli chodzi o iteracyjne podejście do rozwoju języka. Zamiast latami dopiekać konkretną funkcjonalność za zamkniętym drzwiami, aby jednym siarczystym wielkim wybuchem dostarczyć ją jako całość, ze względu na ambitny zakres poszczególnych projektów, niezbędne jest stopniowe dopasowywanie platformy do ich wymagań. Dość powiedzieć, że upór, z jakim architekci JDK usuwają SecurityManagera mocno związany jest z faktem, jak bardzo ciężko jest pogodzić jego istnienie z Projectem Loom, co swego czasu podkreślał Ron Pressler.

Podobnie sprawa wygląda z Valhallą. Wprawdzie do ukończenia projektu jeszcze trochę, ale już dziś twórcy dostarczają nam narzędzia, które pozwolić mają na jak najmniej gwałtowny szok, kiedy już Value Classes ostatecznie trafią do naszego CodeBase. Jednym zaś z mechanizmów, który na to pozwala są ostrzeżenia ze strony kompilatora.

Blog softwaregarden.dev opublikował tekst, w którym na czynniki pierwsze rozebrał JEP 390: Warnings for Value-Based Classes, który trafił do JDK wraz z Javą “szesnastką”. Przynosi on szereg ostrzeżeń, które pomóc nam mają “wyłuskać” z naszego kodu źródłowego użycia konstrukcji języka, które będąc w tym momencie zupełnie legalnymi, po wydaniu Valhalli w orkiestrowy sposób wysypią nam kompilacje. To, co w tekście jest szczególnie interesujące to fakt, że każdy z problemów dostaje dość jasne rozłożenie na czynniki pierwsze z klarownymi propozycjami rozwiązań. Dzięki temu stanowi znacznie lepszą pomoc niż jednak dość kryptyczne ostrzeżenia dostarczane przez JVM.

A czy TY jesteś gotowy na Valhallę?

Źródła:

3. Jak JetBrains radzi sobie z tworzeniem Kotlinowego IDE?

A na koniec, Kotlin

Dwa tygodnie temu mieliśmy okazję podzielić się z Wami informacją o publikacji nowej edycji kotlinowej roadmapy, gdzie szybko przybliżyliśmy najbardziej interesujące aspekty tego, co inżynierowie i programiści języka mają zamiar dostarczyć nam w ciągu następnych dwóch miesięcy. Jednym z aspektów, który szczególnie przykuł moją uwagę był fakt, że dość istotną częścią tych planów stanowiło ulepszenie wydajności samego kotlinowego IDE. Zastanawiałem się wtedy jakież to prace są planowane w tym kontekście. Jetbrainsi nie pozostawili mnie oczywiście długo w niepewności i opublikowali naprawdę szczegółowy artykuł, w którym wgryzają się we wszelkie technikalia swoich planów.

Muszę przyznać, że choć sam nie jestem wielkim pasjonatem usprawnień wydajnościowych devtoolsów, to jednak publikacja Antona Yalysheva robi wrażenie. Porusza on w niej szereg bardzo interesujących aspektów. Jednym z nich są sposoby syntetycznego mierzenia wydajności operacji wykonywanych w IDE czy też opisanie zakresu prac, jaki niezbędny jest aby móc sprawić, że codzienna praca programistów i ogólny “developer experience” samego IDE poprawią się na lepsze. Okazuje się bowiem np. że tak
naprawdę sprawdzanie składni odbywa się nie w wyniku jednego “checkera”, a dwóch – jednego przeznaczonego dla problemów z lintingiem, a drugiego dla potencjalnych błędów kompilacji – tak zwanych “błędów czerwonych” jak określa je sam artykuł. Takich interesujących detali jest w tekście sporo, a całość kończy się dodatkową sekcją, gdzie Anton dzieli się z nami dalszymi potencjalnymi planami. Tak więc, o ile jest to pewnie tekst w swojej naturze przeznaczony do dość niszowej grupy, to jednak polecamy jego lekturę w zasadzie każdemu pasjonatowi Kotlina.

PS: Swoje własne Highlighty w kontekście roadmapy ich języka dostarczyło też Jetbrains.

PS2: W zeszłym tygodniu ukazał się też kolejny, czwarty kamień milowy Jetpack Compose for Desktop – raczej nudny. Najciekawszymi jego aspektami jest chyba wsparcie dla applowskiego M1 oraz fakt, że sam Compose dostał wsparcie dla kompilacji do formatu Kotlin/Native – sprawia to, że sam projekt jest teraz w pełni multiplatformowy.

Źródła

1. Nie znudził się Wam jeszcze JEP-411? Bo temat nie chce zdechnąć

2. Tonight, we dine in Valhalla – jak już dzisiaj przygotować swój codebase

3. Jak JetBrains radzi sobie z tworzeniem Kotlinowego IDE?

Odkryj więcej świetnych treści!