Co przyniesie przyszłość Projektu Amber? JVM Tuesday vol. 103

1. Czy Projekt Panama może służyć jako NIO 2.0?

Zanim jeszcze skupimy się na wysypie newsów (a przez dwa tygodnie się ich trochę nazbierało…), chciałem na rozgrzewkę podzielić się z Wami nowym, świeżym podejściem do projektu Panama. Przyznam, że mnie samemu Panama cały czas kojarzyła się z aplikacjami, które wymagają dostępu do natywnej pamięci czy innych zasobów systemu, albo komunikacji między procesowej. W dużej części wynika to z tego, że w mojej głowie Panama jest rozumiana jako zbiorcza abstrakcja nad JNI i sum.misc.Unsafe, podanej w nowym, bezpieczniejszym API.

Podejrzewam, że nie jestem jedyny. Wydaje mi się więc, że tytuł artykułu Panama: Not-so-Foreign Memory, który Gavin Ray nadał swojemu artykułowi trafia w punkt – bowiem Project Panama poza lepszą natywną interoperacyjnością przynosi sporo więcej. Sprawia to, że może być przydatny również tam, gdzie na pierwszy rzut oka go o to nie podejrzewamy.

Bawiliście się kiedyś NIO? Pod tym skrótem kryje się Java Non-Blocking IO, które było jednym z najważniejszych dodatków jeszcze za czasów Javy 1.7. Jeśli mimo wszystko nie macie z nią większego doświadczenia, to nie czujcie FOMO – jest to API używane głównie przez asynchroniczne biblioteki jak Netty czy sterowniki baz danych. Dla ZwykłegoUżytkownika™️ jest ono mocno nieprzystępne i raczej nie chcecie widzieć jego użycia w typowo „biznesowym kodzie”.

Dlatego właśnie tak bardzo spodobał mi się tekst Gavina Raya, w którym pokazuje on jak można użyć wprowadzonego w Panamie MemorySegment API w miejscach, gdzie wcześniej niezbędne było używanie NIO. Tekst pokazuje, że w wypadku np. wspomnianych sterowników baz danych można zmienić podejście i traktować dane nie jako ciągły strumień bajtów, a jako dyskretne pakiety o konkretnej strukturze. Dzięki temu uzyskujemy sporo więcej wsparcia od samego języka, a także bezpieczeństwo pod postacią otypowanych struktur pamięci. Więcej znajdziecie w tekście Gavina, który jest zaskakująco przystępny w lekturze, biorąc pod uwagę tematów które dotyka.

Przynajmniej pod warunkiem, że Panama nie kojarzy się Wam z kapeluszami.

Źródła

• Panama: Not-so-Foreign Memory

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 przyniesie przyszłość Projektu Amber?

Po Panamie w naturalny sposób przychodzi czas na Project Amber, którego celem jest zapewnienie jak najlepszego Developer Experience całej społeczności. Brian Goetz – prawdziwy tytan JVM – wyraźnie się nudzi albo prokastrynuje, żeby Valhalla czasem nigdy nie wyszła (sorry Brian, musiałem), ponieważ w ostatnich tygodniach listy mailingowe Ambera zostały wręcz (oczywiście jak na javowe Listy Mailingowe) zalane wręcz nowymi pomysłami. Przyglądnijmy się więc tym, co znajdziemy w propozycjach.

Zacznijmy od tak zwanych „nienazwanych zmiennych”. Jeżeli macie jakieś doświadczenie ze Scalą to – po pierwsze – jeszcze trochę w tym wydaniu będzie dla Was oraz – po drugie – kojarzycie pewnie operator underscore _, który używany jest wtedy, gdy nazwa parametru nie jest istotna. Nieco uproszczonym w stosunku do Scali użyciem jest też np. it w Kotlinie i Groovym. Java miała historycznie kilka podejść do podobnej konstrukcji składniowej, jednak ostatecznie nic z nich nie wyszło. Teraz Brian chciałby do tematu wrócić i prosi o feedback nad różnymi potencjalnymi sposobami użycia tej struktury. Jeżeli jesteście ciekawi, dlaczego jest to na tyle skomplikowane, że historycznie już inicjatywa kilkakrotnie spadła z rowerka, zachęcam do zapoznania się z wątkiem w ramach listy mailingowej.

Ogólnie, całość ma pozwalać na zastąpienie skomplikowanego:

x instanceof String[] arr
  && arr.length matches L
  && arr.length >= n
  && arr[0] matches P0
  && arr[1] matches P1
  ...
  && arr[n] matches Pn

prostym

String[L] { P0, .., Pn }

Stąd w płynny sposób przechodzimy do ostatniego z maili dotyczących Ambera, który ma na celu również wprowadzenia pattern matchingu dla typów prymitywnych. Powyższa składnia używająca instanceof jest problematyczna, ponieważ… typy prymitywne nie mają instancji i użycie operatora się z nimi mocno kłóci. Okazuje się, że znalezienie dobrej alternatywy nie jest to wcale aż taki prostym procesem, biorąc pod uwagę skomplikowane reguły AutoBoxingu i castowania. Tak jak powyższe, dyskusja jest tutaj super ciekawa (po drodze zboczyła w mocno filozoficzne wywody w rodzaju rzeczywistego znaczenia operatora instanceof) i jeżeli chcecie poznać trochę obskurnych detali Javy, bardzo polecam przebicie się przez ten wątek prawie pięćdziesięciu maili.

A jak już jesteśmy przy Listach Mailingowych – to na koniec drobnica. Otóż ogłoszono, że wraz z JDK 20 ostatecznie stracimy możliwość targetowania naszego buildu jako kompatybilnego z JDK 7. Ostatnio informowaliśmy, że samo JDK 7 traci już w zasadzie zupełnie wsparcie, ta decyzja to de facto przyklepanie tematu również od strony bebechów JVM.

Źródła

• Unnamed variables and match-all patterns
• FYI, planning to drop support for -source/-target/–release 7 from javac in JDK 20
• Array patterns (and varargs patterns)
• Primitives in instanceof and patterns

3. Akka przestaje być w pełni otwarto-źródłowa, zmienia licencję

No, to techniczne sprawy mamy za sobą, teraz czas przejść do prawdziwej burzy ostatniego tygodnia.

Akka to w dzisiejszych czasach jeden z głównych trzonów Scali i jeden z głównych powodów, dla których to właśnie tym językiem interesują się firmy. Jest to jedna z najlepszych w całej branży implementacji modelu aktorowego, który dzięki wsparciu dojrzałej (i dobrze znanej w branży) platformy – jaką jest JVM – stanowiła prawdziwie bardzo kuszącą kombinacje. Dlatego też tak dużym echem w branży odbiła się w świecie programistycznym wiadomość, że od wersji 2.7 Akka zmienia model licencyjny z Apache 2.0 na BSL v1.1 (Business Source License), stworzonej przez MariaDB. Zmiana licencji oznacza w zasadzie zamknięcie etapu rozwoju Akki w oparciu o tak zwany „Open Core”.

Co BSL oznacza dla Akki w praktyce? Otóż nowe wersje będą w dalszym ciągu publikowane pod Apache 2.0, jednak ze sporym opóźnieniem – dopiero po trzech latach. Do tego czasu każda nowa wersja będzie co prawda udostępniana wraz ze źródłami, ale za darmo będzie wolno z niej korzystać wyłącznie na środowiskach nieprodukcyjnych. Jeżeli będziemy chcieli użyć Akki w systemie produkcyjnym, a roczny przychód naszej firmy przekracza 25 milionów dolarów, niezbędne będzie uiszczenie opłat licencyjnych. Ich ceny zaczynają się od około $2,000 USD za rdzeń procesora, definiowany jako rdzeń sprzętowy / vCore / vCPU. Jeżeli chcemy zmodyfikować Akkę na swoje potrzeby, licencja wyniesie nas $72,000 USD. Całość jest nieco bardziej zniuansowana, więc po szczegóły pricingu odsyłam Was tutaj.

Twórcy Akki wydali specjalny post, w którym tłumaczą przyczyny swojej decyzji. Mamy tutaj do czynienia z tradycyjnym problemem małej firmy, z której efektu pracy korzystają duże korporacje w zasadzie bez dawanie niczego od siebie. Akka stała się artefaktem swoich czasów – dzisiaj popularne projekty Open-Source, typu Deno czy Vercel bardzo szybko wchodzą w rynek Venture Capital, natychmiast próbując się monetyzować przez np. tworzenie odpowiedniego produktu infrastrukturalnego. Lightbend też próbował tej ścieżki, inwestując w Akkę Serverless, która w maju tego roku została przemianowana na Kalix i wydana jako osobny produkt. Widać jest to trudne do zrobienia tak bardzo retroaktywnie.

Zdaje sobie sprawę, jaki popłoch w społeczności wywołała decyzja Lightbendu (niech świadczy o tym ilość dyskusji, które pojawiły się na popularnych agregatorach), ale akurat decyzja jest z mojej strony zrozumiała. Akka po prostu „robi robotę” – dlatego też zresztą stanowi jeden z trzonów Scali. Lightbend nie jest to pierwszy podmiot, który decyduje się na podobny ruch. Początek zeszłego roku przebiegł pod znakiem konfliktu Amazon vs Elastic, gdzie ten drugi zdecydował się na licencje SSPL (Server Side Public License), która wycelowana jest akurat w ograniczenie użycia projektów OpenSource przez dostawców chmurowych. Równocześnie, mam trochę obaw czy zapisy licencyjne, a prawdopodobnie również idąca za nimi konieczność umożliwienia audytowania nie będą stanowić bariery wejścia dla wielu mniejszych (ale pewnie też większych) firm, które po wstępnym „capacity planning” zdecydują się jednak sprawdzić inne rozwiązania lub ogólnie alternatywną architekturę. Nie bez powodu OracleDB zwykle używany jest przez banki i duże podmioty.

Co ciekawe, ten ruch afektuje nie tylko bezpośrednich użytkowników Akki. Przykładowo, okazało się, że Apache Flink używa w swoich internalach Akki, i poinformowali swoją społeczność o tym, że ich projekt pozostanie na otwartej wersji 2.6, a w międzyczasie będą zastanawiać się co robić dalej. Pewnie podobnych problemów będzie więcej.

Także na koniec mam jeszcze dla Was jedno ciekawe, nie-JVMowe źródło. W społeczności od dłuższego czasu trwa dyskusja nad sposobami finansowania projektów open-source, zarówno tych dużych i małych. Okazuje się, że jako dość kreatywna branża udało nam się wypracować trochę modeli, a świetną agregatą jest repozytorium o uroczej nazwie Lemonade Stand, nawiązujące do najlepszych kapitalistycznych tradycji. Oczywiście, daleko mi od sugerowania, że Akka powinna w ten sposób zarabiać na dalsze utrzymanie projektu, ale podejrzewam, że któryś z naszych czytelników posiadający jakieś projekty otwarto źródłowe znajdzie tam coś dla siebie, co pozwoli choć trochę zrekompensować społeczności czas wkładany w pracę.

PS: VirtusLab – firma w której pracuje – jest Partnerem Lightbend. Wszystko, co przeczytaliście powyżej jest moimi prywatnymi przemyśleniami i nie należy traktować go jako stanowiska organizacji jako takiej.

Źródło

• Lightbend Changes its Software Licensing Model for Akka Technology
• Regarding Akka’s licensing change
• A handy guide to financial support for open source
• Why We Are Changing the License for Akka

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!

4. Release Radar

Nie było mnie dwa tygodnie, a to sprawiło, że nie tylko dużo się wydarzyło, ale obrodziło również nowymi wydaniami popularnych projektów

Scala 3.2

Skoro tyle było dzisiaj o Akce, to zacznijmy od Scali. Poza beczką dziegciu kontrowersyjnych w społeczności decyzji licencyjnych, pewnym plastrem miodu było wydanie nowej Scali 3.2.0. Przynosi ona bowiem sporo interesujących nowości.

Po pierwsze, ucieszą się wszyscy Ci, których ulubioną metryką jest pokrycie kodu testami. Najpopularniejszy scalowy plugin służący do tego jeszcze za czasów Scala 2 – Scoverage – mocno bazuje na outpucie kompilatora, który w nowej Scali się zmienił. Na szczęście to się zmienia i Scala 3.2 wprowadza nie tylko generowanie niezbędnego outputu, ale również plugin do sbt orkiestrujący cały proces. Dodatkową rzeczą, która związana jest z narzędziową jest wprowadzenie nowej flagi -Vprofile, generującej statystyki dotyczące złożoności kodu źródłowego.

Nowa Scala to również sporo syntax-u, który daje programistom Scali jeszcze więcej mocy, jak choćby lepsze podpowiadanie kodu, słodziki składniowe dla extension functions czy for-comprehension oraz wiele więcej min. kilka nowych, eksperymentalnych API. Ale po to odsyłam Was już do pełnych release notes.

Quarkus 2.12.0

Nowy minor Quarkusa 2.12.0 to nie taki znowu minor, zwłaszcza dla użytkowników GraalVM i Kotlina. Te zostały bowiem zaktualizowane do wersji odpowiednio 22.2 oraz 1.7, dzięki czemu możemy w pełni korzystać z dobrodziejstw nowych edycji – z których moim zdaniem (odpowiednio) najciekawszymi będą mniejsze rozmiary obrazów dla GraalVM oraz lepsze wsparcie inkrementalnej kompilacji dla Kotlina. Użytkownicy Microsoft SQL Server dostali zaś aktualizacje sterownika JDBC.

Jeżeli nie używacie żadnego z powyższych, jedyne co nowe wydanie ma do zaoferowania to wsparcie Sekretnych Kluczy w plikach konfiguracyjnych – funkcji udostępnianej przez udostępnianej przez SmallRye Config.

Helidon Níma w wersji Alpha

A na koniec prawdziwa gwiazda – oficjalna zapowiedź Helidon Níma. Tak, tego samego Helidon Níma o którym pisaliśmy w kontekście „scoopu” z EclipseConf, a który wreszcie doczekał się oficjalnej zapowiedzi, a także… nazwy. Okazuje się bowiem, że Nima to tak naprawdę Níma.

Na razie ukazała się wersja Alfa, a na pełną przyjdzie nam jeszcze poczekać – twórcy zapowiedzieli bowiem, że pracę nad nią powstaną mniej więcej do końca przyszłego roku, kiedy należy się spodziewać jej stabilnego wydania, równoległego do Helidona 4.0. Jak na tak wczesny etap otrzymaliśmy już całkiem sporo szczegółów technicznych – towarzysząca postowi premierowemu publikacja Thomasa Langera skupia się na tym, jak Níma na tym etapie prezentuje się w porównaniu z Microprofilowym Helidonem, a także z bezpośrednią konkurencją, za jaką twórcy uznają Netty’ego. Jak można przeczytać, jednym z celów Nímy jest właśnie całkowite wyrugowanie Netty’ego z Helidonowego ekosystemu.

Ja już więcej nie idę na urlop 😅 Wystarczy, że mnie chwilę nie ma, a potem odkopuję się przez dwa dni z tematów, a i tak nie wyczerpałem wszystkiego… ale to już sobie zostawimy na za tydzień.