JVM Wednesday vol 93 - Czym jest programowanie zorientowane na dane?

1. Czemu Projekt Amber to programowanie zorientowane na dane?

Ze wszystkich JVM-owych projektów, Amber jest tym, który dostaje chyba najmniej serducha społeczności i jest najmniej dookreślony. No bo czym jest ten legendarny „Developer Experience” czy „produktywność”, która przyświeca Amberowi? Cały projekt to taka swoista parasolka, pod którą chowa się w zasadzie wszystko i trudno jest znaleźć jeden termin, elegancko spinający wszystkie znajdujące się pod nią inicjatywy.

Dlatego też moje oczy przykuł tak bardzo artykuł Briana Goetza (nie jest to pierwszy raz, gdy edycję zaczynamy od niego), w którym postanowił on użyć do opisania zestawu funkcjonalności które Amber przyniósł (takich jak var, rekordy, sealed classy czy pattern matching) terminu Data-Oriented Programming – programowanie zorientowane na dane. Jak pisze sam autor

Programowanie zorientowane na dane zachęca nas do modelowania danych jako (niezmiennych) danych, a kod, w którym zawarta jest logika biznesowa dotycząca działania na tych danych, powinien być przechowywany oddzielnie.

Czyli w skrócie… anemiczne obiekty i serwisy które je obsługują… coś co programiści Springa robią w zasadzie od zawsze.

Ale to tak naprawdę wierzchołek góry lodowej. Tekst Goetza, który serdecznie polecam, to poza technicznym wprowadzeniem w najnowsze zdobycze Javy także naprawdę ciekawa, nieco filozoficzna dekompozycja tego, czym jest programowanie obiektowe. Brian dokonuje próby zrozumienia, dlaczego OOP nie jest już tak popularne jak kiedyś. Jednym z możliwych powodów w jego oczach jest… odejście od Monolitu i regularne zmniejszanie rozmiaru naszych projektów (mikroserwisy, funkcje serverless).

A jeżeli nie macie ochoty na filozofię – jest to też spójny „tutorial” ostatnio dodanych featurów.

Ale nie tylko o Amberze pisano ostatnio w społeczności. Na blogu Inside Java pojawiła się druga część gościnnej serii dotyczącej projektu Panama stworzonych przez Denysa Makogona. O Panamie, czyli daniu programistom Java dostępu do zasobów systemu mieliśmy okazję pisać niedawno w kontekście eksperymentów z algorytmami sortowania, ale ciężko tamten artykuł nazwać dobrym… wprowadzeniem. Tekst Makogona znacznie lepiej sprawdza się jako praca u podstaw.

A… w sobotę pisałem, że nie miałem okazji oglądać w ramach Confitury prezentacji Jarka Pałki „Bare Metal Java” (co jest tutaj zakamuflowaną nazwą na Project Amber), ale we wtorek na Segfaultowym Meetupie wreszcie mi się udało. Serdecznie polecam – super wprowadzenie do tego, co ze sobą przynosi natywna pamięć i natywne funkcje.

2. Nadchodzi nowy JBoss EAP

Zwykle, gdy piszemy o Jakarcie EE, dyskusja kręci się o samej specyfikacji albo WildFly’a – najbardziej „prężnego” ze wszystkich serwerów aplikacyjnych. Jest ku temu dobry powód – to właśnie „ważka” jako jedyny z serwerów aplikacyjnych rozwija się w dynamiczny sposób. Taki na przykład JBoss EAP (Enterprise Application Platform, nie Early Access Preview) ukazuje się dość rzadko, ale też dlatego każda nowa „duża wersja” stanowi spore wydarzenie. Dlatego też sam fakt ogłoszenia przez RedHata, że początkiem przyszłego roku pojawi się jego ósma edycja przykuwa wzrok.

JBoss EAP jest oparty na znanym naszym czytelnikom WildFly’u. Jeżeli twórcy będą chcieli zapewnić pełnie kompatybilności (a to zapowiadają), będą musieli oprzeć się na WildFly w wersji minimum 27. Twórcy JBossa celowo ominęli Jakarta EE 9 – ta bowiem wiązała się głównie z migracją namespace javax.* na jakarta.* . RedHat bał się, że wymuszanie tak niebiznesowej zmiany na twórcach aplikacji okaże się być strzałem w kolano i potencjalnie wypłoszy pozostałych przy projekcie programistów.

Co ważne, już końcem roku użytkownicy będą mieli okazję przetestować – wtedy pojawi się bowiem wersja Beta nowego wydania.

Miłego migrowania namespaców. Chwała JetBrains za narzędzia i tutoriale.

3. Release Radar: ZIO, jOOQ i Quarkus

ZIO 2.0

ZIO to jedna z popularniejszych scalowych bibliotek, implementacja Monady IO. Monada IO jest specjalną monadą, która opakowuje wyrażenia w sposób umożliwiający „funkcyjny czyste” wykonywania operacji wejścia-wyjścia (IO). Co wprowadza druga edycja?

Zacznijmy od informacji, która już niedługo zacznie pewnie pojawiać się coraz częściej – nowe ZIO zostało zoptymalizowane pod Looma. To zresztą nie jedyna konotacja z Javą – twórcy chwalą się, że API biblioteki zostało usprawnione i ma teraz być przyjemniejsze w użyciu dla programistów, którzy mają więcej doświadczenia z Javą. Poprawieniu uległy funkcje streamingu, a także wydajność całości. Twórcy chwalą się też usprawnieniem monitoringu.

Cały blog post z ogłoszeniem jest bardzo ciekawy i pełen szczegółów, a jeśli zainteresował Was temat Monad IO – zapraszam do bardzo dobrego opracowania w formie 36 minutowego filmiku

jOOQ 3.17.0

W ostatnim tygodniu pojawił się również jOOQ w wersji 3.17. Nowa wersja „pod maską” lepiej wspiera teraz zarówno reaktywność, jak i kotlinowe korutyny. Nowa wersja porzuca również wsparcie zarówno dla Javy 8, jak i Javy 11 – darmowa wersja uruchomi się jedynie z Java 17. Jeżeli jesteście zmuszeni używać starszych LTS-ów, pozostaje Wam tylko wersja komercyjna. W zamian za to, twórcy obiecują szersze wsparcie dla funkcjonalności dostępnych w nowej Javie (jako efekty Projektu Amber), jak rekordy czy sealed classy.

Jeżeli chodzi o funkcjonalności, to z pewnością największą nowością są kolumny wyliczane wyłącznie na potrzeby klienta. Można je potraktować jako „widoki” zapisane w jOOQ, dla poszczególnych kolumn. Szczególnie użyteczną kombinacją funkcji jest połączenie tych kolumn wyliczanych z nowym modyfikatorem widoczności, który umożliwia zachowanie leżących u ich podstaw kolumn podstawowych jako prywatnych, a więc niewidocznych dla kodu użytkownika. Pozwalają też na generowanie kolumn audytowych. Niestety, funkcjonalność dostępna jest jedynie w wariancie komercyjnym. Ten też otrzymuje ulepszenie wsparcia dla transformowania między formatami.

To nie dla Open-Source, dla pana commercial support to

Z drobniejszych zmian – pojawiło się wsparcie dla nowych typów danych PostgreSQL, a także nowe API dla Implicit (dorozumianych) JOINów. Te już trafiły do wszystkich.

Quarkus 2.10

Na koniec zaś nowy Quarkus 2.10, który podobnie jak poprzednicy jest bardzo interesujący.

Dopiero co przy okazji ZIO przewidywałem, że Loom zacznie się panoszyć wśród zapowiedzi nowych funkcjonalności, by móc do tematu wrócić teraz – Quarkus zapowiedział bowiem pierwsze przymiarki do wsparcia Looma. Zrobił to w iście javowym stylu, ponieważ dodano po prostu… adnotacje @RunOnVirtualThread.

Większość zmian kręci się właśnie w koło asynchronicznego I/O. Dostajemy bowiem usprawnienia SmallRye Reactive Messaging, wsparcie Kubernetesa w Reactive SQL Client oraz nieblokujący wariant wsparcia do GraphQL. Drobne usprawnienia trafiły do quarkus-cache i quarkus-bootstrap-maven-plugin.

JVM Wednesday vol 93 – Czym jest programowanie zorientowane na dane?