JVM Tuesday vol. 25

I stało się, po niezwykle ekscytującym tygodniu poprzednim (z dużymi wydaniami Kotlina i Javy oraz dyskusjami z tym związanymi), tym razem… no cóż, odrobinę posucha. Z czystym sumieniem ciężko nam było znaleźć aż trzy dobre tematy do dzisiejszej edycji.

Trzymamy się więc naszych zasad – nie chcemy paść Waszego FOMO i dzielić się mało interesującymi materiałami, tylko po to, aby wypełnić wierszóweczkę

Po tym nieco przydługim wstępie, zapraszam do lektury!

1. JEP draft: Frozen Arrays (Preview)

JDK 16 ledwo otrzymała swojego Release Candiate (a od czasu, kiedy o tym informowaliśmy, pojawiła się już jego druga iteracja), ale to nie znaczy, że architekci JVM wzięli sobie wolne. Kiedy my dyskutujemy nad wyższością Rekordów nad Lombokiem, pojawiają się nowe drafty funkcji. Zapewne będziemy mieli okazję pobawić się nimi dopiero w okolicach Javy 18 (co, biorąc pod uwagę tempo wydawania nowych wydań JDK, nie jest znowu jakąś niewyobrażalnie odległą przyszłością).

Naszą małą tradycją stało się już wyłapywanie tych najbardziej interesujących zapowiedzi i nadawanie im nieco kontekstu. Dlatego też dzisiaj mamy dla Was tak zwane Frozen Arrays (biorąc pod uwagę warunki pogodowe ciężko było chyba wybrać bardziej pasującego proposala). Jednak Frozen Array wpasowują się nie tylko w ten dość mroźny luty, ale również w szeroko rozumiane programistyczne mody. Od paru lat nieprzerwanie trwa w naszej branży trend w kierunku niemutowalności. “Grzebanie” w obiektach staje się symbolem złego smaku, z jednej strony nie bez przyczyny (łatwo jest wyeliminować całe klasy błędów związane np. z wielowątkowością), z drugiej strony całość przybiera czasem znamiona cargo cultu, jakich wiele w naszej branży.

Niechcący odkryłem, że to o czym piszę ma własną stronę na Wikipedii

Zalety niemutowalnych obiektów są jednak na tyle praktyczne (oryginalny proposal wypisuje ich naprawdę długą listę), że nasze języki prześcigają się w zapewnianiu wsparcia dla tego paradygmatu (patrzę na Ciebie, Kotlinie). Celem “zamrożonych tablic” jest udostępnienie wariantu klasycznych “arrajek” blokujących blokującego możliwość późniejszej podmiany istniejących w niej elementów, czyli prostego przypisania x[i]=y. Proponowana składnia nie jest jeszcze ostateczną, ale zaprezentowany wariant przypomina nieco Object.freeze znany programistom JavaScripta:

T[] src = ...;
T[] dest = System.arrayfreeze(src, 0, src.length);

Muszę przyznać, że na ten moment składnia nie jest zbyt urodziwa, ale proponowane jest jej “docukrzenie” poprzez np. rozszerzenie interfejsu tablic o metodę .freeze. Próba dokonania mutacji na tablicy ma rzucić ArrayStoreException (co, liczyliście że system typów Was przed tym uchroni? Naiwniacy ).

To, co szczególnie ciekawe w wypadku tego JEPa, to fakt, że niesie on za sobą wiele nieoczywistych reperkusji. Mutowalność tablic jest czymś tak głęboko zakorzenionym w samej strukturze maszyny wirtualnej, że do implementacji wspomnianej zmiany potrzebne może być wprowadzenie poprawek w Java Memory Modelu. Jest to jednak związane głównie z faktem otwierających się przed twórcami JVM nowych potencjalnych poprawek, gdyż zmrożone tablice będą “efektywnie finalne”, co pozwala na pewne agresywniejsze optymalizacje.

Jak zwykle polecamy lekturę całego JEPa, który zawierającego masę dodatkowych szczegółów na “dla chętnych.”

Kryptyczna wrzutka: Jeden z tych dwóch panów był moim role-modelem w dzieciństwie, a drugi nazywa się Anianiasz

Źródła:

2. Przegląd rozwiązań do tworzenia desktopowych aplikacji na JVM

Od pewnego czasu w zastałym nieco świecie JVMowych aplikacji desktopowych, pojawia się zaskakująco dużo inicjatyw. W przeciągu kwartału dostaliśmy choćby nową edycję JavyFX, a Jetbrains wypuściło Jetpack Compose for Desktop – trochę nawet korciło mnie, żeby przygotować tekst w jakiś sposób je podsumowujący. Oczywiście, w czasie kiedy ja się nad tym zastanawiałem, ktoś inny po prostu siadł i to zrobił, a mi pozostało tylko przekazać Wam o tym informacje.

Tym kimś jest jednak nie kto inny niż Nicolas Fränkel. Jest to autor niepozornego bloga A Java Geek, który nieprzerwanie od lat pozostaje jednym z najlepszych źródeł powiązanych z JVMem, zawsze z raczej nieszablonowanymi opracowaniami. Od początku roku tworzy on kolejne wpisy w ramach serii The state of JVM desktop frameworks. Opracował już Swinga, SWT (budulec Eclipse), TornadoFX (Framework JavaFX z bindingami do Koltina) oraz Jetpack Compose. Każdy z postów blogowych łapie bardzo dobry balans między wyczerpaniem tematu na tyle, że czytelnik pozostaje z poczuciem zrozumienia wad i zalet każdego z rozwiązań, a wchodzeniem nadmiernie w szczegóły.

Jednak to właśnie najnowsza, szósta część szczególnie ujęła moje serduszko. Otóż autor postanowił przejść w niej przez najróżniejsze sposoby udostępniania Javowej aplikacji klientom. Prezentuje w niej takie historyczne artefakty jak Applety, czy też Java Web Start (a właściwie jego otwartą wersję Open Web Start) – rozwiązania święcące tryumfy w czasach, gdy internet dopiero raczkował (choć nie będę ukrywał, że sam jeszcze miałem okazję, w czasie swojej nie tak długiej przecież kariery, utrzymywać aplikację dystrybuowaną w WebStartowym formacie JNLP). Dla niejednej osoby będzie to ciekawa lekcja historii.

Ja pewnie nie będę spał po nocy przez kilka dni.

Dla tych zaś, co szukają czegoś, co w 2021 roku będzie wyglądało, jak rozwiązanie wyrwane z muzemu, Nicolas prezentuje jpackage (której to stabilne wydanie zostanie opublikowane wraz z JDK 16) oraz pokazuje, jak używając mechanizmu jlink napisać prosty skrypt uruchomieniowy dla Waszego modułu. Na koniec też szybko przechodzi przez bonusową listę alternatywnych projektów, które udało mu się odnaleźć podczas researchu do artykułu. I to właśnie ta zwięzłość i przekrojowość sprawia, że nawet, jeśli nie zamierzasz pisać w najbliższym czasie desktopowych aplikacji, to jest to świetna okazja, żeby odświeżyć sobie nieco temat.

1. JEP draft: Frozen Arrays (Preview)

Źródła:

2. Przegląd rozwiązań do tworzenia desktopowych aplikacji na JVM

Źródła:

Odkryj więcej świetnych treści!