JVM Tuesday vol. 40

1. OpenJDK od Microsoftu wydane

Podobnie, jak w przypadku edycji sobotniej, dzisiejszy “wtorek” rozpoczniemy ogłoszeniem z konferencji Microsoft Build, które nie załapało się do newsów związanych z rzemieślnictwem oprogramowania.

Dla osób śledzących działania Microsoftu z pewnością nie będzie tajemnicą, że firma z Redmond dość mocno inwestuje ostatnio w Javę. Kulminacją jej działań może być fakt, że w zeszłym tygodniu wypuściła ona w końcu swój własny wariant OpenJDK. Na razie dostępna jest wersja JDK 11, ale do wczesnego wglądu trafiła też “szesnastka”. Całość oparta jest o Eclipse Adoptium, którego Microsoft jest sponsorem.

Premierze towarzyszyło również zaprezentowanie odpowiedniego zbioru obrazów dockerowych oraz nowego “hubu”, agregującego wszystkie inicjatywy Microsoftu związane z Javą, jak np. plugin do Visual Studio Code czy szablony do GitHub Actions. Muszę przyznać, że zaskoczyła mnie również mnogość materiałów do nauki tego języka, jakie można tam znaleźć. Java for Azure wydaje się być całkiem interesującym kursem, pozwalającym w praktyce zapoznać się z usługami dostępnymi w ramach chmury Microsoftu.

No cóż, historia zatoczyła koło, i po raz pierwszy od 2007 roku Microsoft znowu posiada własną wersję JDK. Jeżeli jesteście zaś ciekawi, czym w ogóle różnią się poszczególne wydania OpenJDK, zapraszam do świetnego artykułu na ten temat.

Źródła

2. Jakarta EE 9.1 przynosi wsparcie JDK 11

Jakarta EE starająca się być na bieżąco z LTSami Javy

W poprzednim tygodniu ukazała się także “minorowa” wersja standardu Jakarta EE 9. Wydanie to pewnie nie zwróciłoby większej uwagi, gdyby nie fakt, że jego efektem jest ostateczne pozwolenie na zmigrowanie projektów opartych o Jakartę do Javy 11. Fakt, że dopiero teraz, dwa pełne lata po wydaniu ostatniego LTSa, zaczął on być wspierany przez Jakartę jest z pewnością dość smutny i trochę wyjaśnia, czemu “enterprajsowa” Java raczej nie kojarzy się z nowoczesnymi projektami.

Żeby jednak nie było tak smutno, postanowiłem sprawdzić, na ile ekosystem powiązany z Jakartą dopasował się do nowo wydanej wersji i muszę przyznać, że to akurat wygląda znacznie bardziej optymistycznie. W tej chwili prawie wszystkie projekty chwalące się kompatybilnością z Jakartą EE wydały już swoje edycje przechodzące TCK (Technology Compatibility Kit). Za łyżką dziegciu można uznać fakt, że tacy istotni graczej jak JBoss czy WebLogic w dalszym ciągu pozostają zgodni wyłącznie z Jakartą EE 8. Dodatkowo, mimo usilnych prób nie udało mi się znaleźć żadnych zapowiedzi sugerujących, kiedy miałoby się to zmienić.

Cóż, musimy się chyba pogodzić z faktem, że ten świat porusza się do przodu po prostu nieco wolniej.

3. Scope Locals – ciekawy JEP związany z Projektem Loom

Od pewnego czasu odgrażam się, że będę chciał Wam opowiedzieć o jednym z ciekawszych JEPów wydanych w ostatnim czasie. Jako że obecny tydzień jest nieco “wolniejszy”, nareszcie mamy na to dobry moment. Zapoznajmy się zatem z tym, co przynieść mają zmienne lokalne zakresu (moje osobiste, koślawe tłumaczenie wyrażenia “Scope Locals”, proposal znajdującego się obecnie w Draftcie)

Zapotrzebowanie na lokalne zakresy wynika z mojego ulubionego projektu w ramach JVM – Loom. Ze względu na fakt, że Loom zamierza oprzeć się na bardzo leciutkich wątkach (dzięki czemu możliwe staje się tworzenie ich w zasadzie nieograniczonej ilości), musimy bardzo uważać na rozmiar struktur tworzonych na potrzeby każdego wątku (bardzo fajny artykuł na ten temat znaleźć możecie tutaj). Jedną z potencjalnych optymalizacji jest udostępnianie między włóknami (bo tak w Loomie zwą się wątki) jak najwięcej stanu.

Popularne Thread Locals (zmienne przypięte do wątku) od początku były kamieniem w bucie twórców Looma. Rozwiązaniem na nie mają być wspomniane Scope Locals – efektywnie finalne, niemutowalne zmienne lokalne, które mogą być w ramach potrzeb bezpiecznie dzielone między wątkami, zmniejszając ilość niezbędnej pamięci. Każdy wątek-dziecko posiadać ma dostęp do pełnego kontekstu swojego rodzica. Pomysł realizacji tego zadania podkradziony został z Common Lispa i jego “zmiennych specjalnych”,

O Scope Locals można myśleć jako niewidocznych parametrach, które są przekazywane do każdej metody. Mają one możliwość przypisania do zmiennej lokalnej wartości wyłącznie na potrzeby konkretnego zakresu (scope) – po jego zakończeniu wartości zmiennych w nim ustawionych zostanie automatycznie przywrócona. Zachowanie to pozwala np. na zakrycie wartości x i y, w którymś z “dzieci”, bez wpływu na wszystkie inne wątki je używające.

Dość dobrze obrazuje to kod źródłowy z JEPa:

// Declare scope locals x and y
static final ScopeLocal<MyType> x = ScopeLocal.forType(MyType.class);
static final ScopeLocal<MyType> y = ScopeLocal.forType(MyType.class);
{
ScopeLocal.where(x, expr1)
.where(y, expr2)
.run(() -> ... code that uses x.get() and y.get() ...);
}

Jak widać, składnia przypomina trochę znane wszystkim “atomiki” na sterydach. Wartości x i y mogą być przekazywane z wątku “rodzica” do wątku “dziecka”. Metoda run() „wiąże” zaś w tym przypadku x i y z wartościami expr1 i expr2. Podczas wykonywania metody run () wszelkie wywołania x.get () i y.get () zwracają właśnie te wartości. Poza nią, wartości te wracają do oryginalnych, odziedziczonych po rodzicu.

Oczywiście, jak to z Loomem bywa, składnia może się jeszcze wielokrotnie zmienić (zwłaszcza, że mamy do czynienia z niczym innym jak draftem). Scope Locals mają być jednak rozwiązaniem jednego z największych problemów projektu (wspomnianego ThreadLocala), dlatego też stwierdziłem, że warto się nimi z Wami podzielić. Nie ukrywam też, że moja sympatia do tego JEPa na pewno pochodzi z faktu, że podświadomie trochę jednak jestem kryptoclojurowcem, więc wszelkie nawiązania do Lispa w JDK przyjmuje z otwartymi ramionami.

1. OpenJDK od Microsoftu wydane

Źródła

2. Jakarta EE 9.1 przynosi wsparcie JDK 11

3. Scope Locals – ciekawy JEP związany z Projektem Loom

Odkryj więcej świetnych treści!