JDK wkracza w 2023: plany na rok, pierwsze JEPy i retrospektywa funkcji Preview – JVM Weekly vol. 122

1. Co 2023 przyniesie dla Javy?

To żeby dobrze zacząć dzisiejszą edycję: Nicolai Parlog, Developer Advocate Javy w Oracle jak co roku przygotował podsumowanie tego, co twórcy języka szykują na najbliższe dwanaście miesięcy. Żeby przekonać Was, że będzie to najlepiej spędzone 10 minut, żeby zbudować sobie obraz Javy w 2023, warto spojrzeć choćby na zakres tematyczny całości.

W czasie krótszym niż trwa pojedyncze przesłuchanie pełnej wersji piosenki „Again” Archive (co również polecam!) Nicolai przechodzi nie tylko przez Looma czy Panamę, ale również pozwoli Wam lepiej zrozumieć plany na GraalVM, projekt Leyden czy też Liliput. Jeżeli czytacie regularnie ten newsletter, pewnie nazwy te zdążyły się Wam obić o uszy, ale w dalszym ciągu polecam – uwielbiam, jak zgrabnie i dynamicznie udaje mu się przejść przez te wszystkie tematy w tak krótkim czasie – zazdroszczę mu tej zwięzłości w przekazie. Myślę, że jeśli nawet tematy nie są Wam obce, to całość pozwoli Wam zarówno na pewną powtórkę, jak i ułożenie całości w pewnym szerszym kontekście.

No, to teraz wszyscy przestajemy czytać i widzimy się z powrotem za 10 minut (to nie koniec dzisiejszej edycji, mam dla Was jeszcze kilka ciekawych informacji, więc wróćcie po oglądnięciu):

Musicie przyznać, że 2023 zapowiada się bardzo smakowicie. Osobiście liczę, że to jednak jeszcze nie wszystko – w końcu 2022 przyniósł nam sporo niespodzianek.

Źródła

• Java’s Plans for 2023 – Inside Java Newscast #40

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. Pierwsze JEPy AD 2023

A jak już wiemy, co czeka nas w 2023, to czas przyglądnąć się temu, co już przyniósł. Styczeń powoli się rozkręcał, ale ostatni tydzień to sporo ciekawych ogłoszeń i cieplutkich informacji prosto z list mailingowych Javy.

Pierwsza z nich to JEP przygotowywany pod parasolką Projektu Amber: No longer require super() and this() to appear first in a constructor. Należy ona do mojej ulubionej kategorii zmian z jednej strony bardzo praktycznych, z drugiej mocno minimalistycznych, a w dodatku do tego – mocno skomplikowanych i sprawiających, że lepiej rozumiem (i mam nadzieje, że wy również) działanie Javy pod maską. Mowa tu bowiem o próbie eliminacji jednego z bardziej niezrozumiałych dla początkujących, a irytujących dla doświadczonych programistów mechanizmów Javy – wymagania bezpośredniego wywoływania konstruktora klasy, po której się dziedziczy, jako pierwszej operacji w klasie dziedziczącej.

W skrócie, nowy Draft chce umożliwić np. walidację (przykład prosto z JEP-a):

public class PositiveBigInteger extends BigInteger {

    public PositiveBigInteger(long value) {
        if (value <= 0)
            throw new IllegalArgumentException("non-positive value");
        super(value);
    }
}

Zmiana jak zmiana, ma ona jednak dwa bardzo ciekawe aspekty. Po pierwsze (co łatwe do przewidzenia) – nie jest ona tak oczywista do przeprowadzenia, ze względu bowiem na wsteczną kompatybilność czy niektóre przypadki brzegowe tworzenia hierarchii klas, co dobrze zostało opisane we wspomnianym JEP-ie. Polecam jednak jego lekturę też dlatego, że całość ładnie uwidacznia że specyfikacja Javy jako języka oraz specyfikacja JVM mają nieco inny poziom „permisywności”. To, że JVM pozwala na więcej pewnie nikogo nie zdziwi (w końcu powstały na nim takie języki jak Kotlin i Scala), ale tutaj ten rzadko poruszany aspekt został wyłuszczona na prostym do zrozumienia przykładzie.

Informacja o drugiej zmianie, którą przynieść ma Java w najbliższej(?) przyszłości nie pochodzi z JEP-a, a bezpośrednio z list mailingowych. Okazuje się bowiem, że twórcy języka mocno wzięli sobie do serca odświeżenie standardu Javadoc. Rok 2022 przyniósł możliwość dokładania w nim snippetów kodu, aktualnie zaś trwają dyskusje nad możliwością wsparcia dla Markdowna. Twórcy Javy (w tym wypadku Jonathan Gibbons z Oracle) zauważają zalety tego języka znaczników, nie pozostają bezkrytyczni. Wskazują bowiem na kilka problemów, zwłaszcza jeśli chodzi o kompatybilność z obecnymi rozwiązaniami używanymi przez Javadoc, mocno opartymi na HTML-u. I choćby dla powyższej argumentacji warto oryginalną wiadomość i pączkującą z niej dyskusje przeczytać.

Podsumowując tą sekcje – jeszcze w grudniu w ramach issue-trackera Javy pojawiło się kilka nowych pozycji, dotyczących prac nad mechnizmem Class Data Sharingu, poprzez usprawnienia na styku z Garbage Collectorem G1 (1)(2) czy ulepszenia API i lepsze wsparcie innych GC. Nie jest to coś, co mocno wpływa na użytkownika końcowego, ale dziele się tym, ponieważ zmiany te zostały zapowiedziane jako czyszczenie przedpola dla projektu Leyden i pojawią się już w JDK 20.

Ostatniego z JEP-ów omówimy zaś sobie w następnej sekcji – jest bowiem mocno unikalny.

Źródła

• No longer require super() and this() to appear first in a constructor
• On Markdown in (Java) documentation comments…
• CDS improvements with archived Java heap objects

3. Jaka przyszłość czeka ścieżkę Preview – Retrospektywa po czterech latach

Kiedy to minęło… Czy wiecie, że nowy tryb releasowy Javy ma już 4 lata? Pokolenie frameworków JavaScriptowych zdążyło już w tym czasie narodzić się i umrzeć.

Wprowadzone w 2019 roku zmiany nie tylko zmieniły tryb releasu nowych wydań Javy, wprowadzając co sześciomiesięczny release train, ale również w ramach JEP 11: Incubator Modules oraz JEP 12: Preview Features wprowadziły do języka dwie nowe metody testowania funkcjonalności – Preview i Inkubację. Przyszedł teraz najwyższy czas, aby przyglądnąć się temu, jak sprawdziły się w praktyce. Z tej okazji ukazał się specjalny JEP draft: Preview Features: A Look Back, and A Look Ahead, w którym Alex Buckley, Specification Lead for the Java Language, analizuje, co się udało, które obawy się nie spełniły, które zaś miejsca wymagają poprawy.

W skrócie: Preview spełniły pokładane w nich oczekiwania. Pozwoliły one otrzymywać szybszy feedback od społeczności, testować nowe funkcjonalności i (lekko) iterować nad nimi w otwarty sposób. Weźmy choćby pod uwagę, jaki wielki oddźwięk w społeczności (i wysyp publikacji) wywołało udostępnienie wirtualnych wątków jako Preview. Dodatkowo, znacznemu usprawnieniu uległo tempo adopcji nowych funkcji przez twórców wszelakiego toolingu, mogą oni bowiem pracować nad prawie stabilnym API z dużym wyprzedzeniem. Także Preview były świetnym pomysłem, ale…

W tej beczce miodu pojawia się jednak łyżka dziegciu. W początkowych założeniach Preview miał być fazą, w której funkcje języka są już na tyle stabilne, że pozostają w niej relatywnie krótko. W praktyce jednak potrafimy mieć funkcjonalności posiadające czwarte/piąte Preview (patrzę na Ciebie, Pattern Matching). Tekst analizuje powody i te są bardzo różnorodne – głównie jednak sprowadzają się do oczekiwania na rozwój innych części języka i potrzebę dopasowywania się do zewnętrznych zmian. Przykładem może być tutaj druga iteracja Wirtualnych Wątków, która musiała się ukazać głównie ze względu na pojawienie się nowych metod w klasie Thread, zmieniając w ten sposób API złotego dziecka Looma. Każde przedłużające się API to jednak nieco inna historia i inny corner case, co utrudnia wypracowanie jednego, wspólnego rozwiązania. Pewnym rozwiązaniem mogłoby być szersza adopcja fazy inkubacji, ale to też w obecnej formie nie jest rozwiązanie problemu – inkubowane funkcje nie mogą być użyte w innych częściach języka. Ma to sens, są one bowiem z założenia niestabilne, ale z tego względu nie nadają się do rozwijania szerszych inicjatyw.

Konkluzje? Na razie brak, ale po pierwsze mamy do czynienia z Draftem, a po drugie istnieje wartość w samym powrocie do korzeni i zrobieniu sobie retrospektywy. Zobaczymy, jakie wnioski zostaną z takowej wyciągnięte.

Źródła

• JEP 11: Incubator Modules
• JEP 12: Preview Features
• JEP draft: Preview Features: A Look Back, and A Look Ahead

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!

Bonus: Source Buddy i najbardziej Buzzwordowy Saper świata

Żeby ładnie podsumować tą edycję, pełną tematów procesowych mam dla Was dwa projekty, którymi możecie pobawić się już dzisiaj. Oba są na tyle ciekawe, że bardzo chciałbym aby uzyskały nieco większą publikę.

Source Buddy

Pierwszy z nich to Source Buddy, czyli swoisty eval dla Javy, którego pierwszy oficjalny release miał miejsce 4 stycznia. Biblioteka pozwala na przekazanie (jako Stringa) fragmentu kodu Javowego, którego dla Ciebie skompiluje i wygeneruje działające Javowe obiekty. Za przykład niech posłuży ten fragment oficjalnego Readme.

String source = """
        package com.sb.demo;

        public class MyClass implements Talker {
            @Override
            public void say() {
                System.out.println("Hello, Buddy!");
          }
        }""";
Class<?> myClassClass = Compiler.compile(source);
Talker myClass = (Talker) myClassClass.getConstructor().newInstance();
myClass.say();

Czy uruchomiłbym to na produkcji? Broń cię, panie Boże, ale wyobrażam sobie, że w przypadku jakichś małych skryptów lub upili pisanych na własne potrzeby taki bieda-metaprograming może być całkiem użytecznym narzędziem. Dlatego też moim zdaniem warto mieć świadomość jego istnienia.

minesweeper-csp

Drugi z projektów to Saper. Ale nie taki zwykły saper. Projekt Elliota Barlasa, ebarlas/minesweeper-csp stanowi bowiem wprowadzenie do aż dwóch konceptów.

Po pierwsze, jego aplikacja używa Wirtualnych Wątków. Co prawda nie brakuje dobrych projektów pokazujących w praktyce użycie Looma (ja polecam choćby Loom Lab od wspomnianego w pierwszej sekcji Nicolaia Parloga), ale zawsze przytulę chętnie kolejny. Dodatkowo, mamy tutaj do czynienia z grą, której zasady są znane w zasadzie każdemu, przez co unikamy potrzeby tłumaczenia domeny.

Drugim, nawet ciekawszym aspektem projektu, jest przyjęty przez Elliota model współbieżności. Projekt opiera się bowiem na CSP, czyli communicating sequential processes, będącego podstawą tego, jak współbieżność działa min. w takim Go, Clojure czy Kotlinie dzięki Korutynom. Do tej pory ten sposób programowania był poza zasięgiem programistów Javy, ale dzięki projektowi Loom nareszcie poszerzył się wachlarz dostępnych dla nas rozwiązań. Jeśli szukacie dobrego wprowadzenia do CSP polecam wprowadzenie do tematu z Uniwersytetu Stanford, prezentacje Rich Hickey na temat implementacji tej funkcjonalności w Clojure albo po prostu analizę kodu opisywanego minesweeper-csp.

Wspomnienia – moją pierwszą aplikacją okienkową (i jedną z ostatnich) był Saper napisany (i trochę wyklikany) w Borland C++. Mało która aplikacja sprawiła mi potem tyle radości.