JVM Tuesday vol.76 - Uczenie Maszynowe w standardzie Javy, jOOQ, Java EE

1. jOOQ pozbywa się wsparcia dla Javy EE na rzecz Jakarty

Jestem prawie pewien, że większość z Was uważa Jave EE za coś mocno niszowego i nie dotyczącego Waszych projektów. Równocześnie, ja z uporem godnym lepszej sprawy szprycuje Was informacjami na temat tej specyfikacji, prezentując kolejne nowości specyfikacji. Dlatego też mam dzisiaj dla Was ciekawe opracowanie, które udowadnia, że może moja cała praca nie idzie tu w piach.

Aczkolwiek nie robię sobie większych złudzeń

Używacie jOOQa? Podejrzewam, że na to pytanie już sporo osób jest w stanie odpowiedzieć twierdząco – nie jest to może poziom Guavy, ale jednak swego czasu był to jeden z szybciej rosnących projektów. Jego gwiazda trochę przygasła, co nie zmienia faktu, że dalej jest to jedna z najciekawszych alternatyw dla wszędobylskiego Hibernate. Wraz z wersją 3.16, stanęli przed ciekawym wyborem – jako, że używają niektórych zależności pochodzących z Enterprise Edition (jak JAXB, JPA i Bean Validation), stanęli przed trudnym wyborem: migrować się, czy też nie migrować. Nie trzymając Was w niepewności – od wersji 3.16 twórcy jOOQ zdecydowali się na zupełne porzucenie wsparcia dla Javy EE. Podbicie wersji będzie wymagało więc repakietyzacji części zależności.

Ciekawe jest również rozwiązanie docelowe. Otóż twórcy stwierdzili, że w związku z ostatnim zamieszaniem będą starali się w przyszłości wyjść zupełnie z zależności enterprajsowej Javy. Nie określili się jeszcze kiedy to nastąpi, ale tak widzą przyszłość swojego projektu.

A jak już jesteśmy przy Javie EE – strasznie symptomatyczne jest dla niej to, że w momencie kiedy wszyscy już dawno opublikowali swoje podsumowanie roku 2021, to Jakarty EE pojawiło się… wczoraj. Przypomniał mi się stary komiks o przeglądarkach i szybkości Internet Explorera.

Źródła

2. Uczenie Maszynowe trafia do standardu Javy

A na koniec pewien drobiazg, z mojej perspektywy jednak bardzo interesujący.

Był takie okres w 2021, gdzie dość dynamicznie zaczynały się pojawiać rozwiązania do Machine Learningu celujące w programistów Javy. Zarówno Oracle, jak i LinkedIn próbowały zaprezentować społeczności swoje rozwiązania, ale jak głośno było na początku, tak ostatnimi czasy i o Tribuo, i o Dagli jest relatywnie cicho. Nie zmienia to jednak faktu, że przestrzeń ML-owa jest zbyt łakomym kąskiem żeby go ot-tak odpuścić.

Javowy ekosystem nie poddaje się więc, o czym świadczyć może formalna akceptacja dla prac nad JSR-381 Visual Recognition (VisRec) Specification. Wbrew dość mylącej nazwie, ma to być standard wysokopoziomowego API dla zarówno podstawowego uczenia maszynowego (ML), jak i klasyfikacji obrazów i rozpoznawania obiektów. JSR 381 ma zapewnić wspólnego API dla MLa, wspólnego dla różnych domen. Jego referencyjna implementacja jest oparta na bibliotece Deep Netts (damn, nie znałem tego), ale całość już w tym momencie wspierana jest przez DJL, bibliotece stworzonej przez Amazon (damn #2, tego też nie znałem 😭). Przykładowe użycia znajdziecie choćby na GitHubie, a pełny tekst specyfikacji ściągniecie ze strony Oracle.

A całą prezentacje pokrywającą temat znajdziecie tutaj

Ta ciekawostka niech pozwoli nam też wyjaśnić czym w ogóle JSR jest. Jako, że Java rozwijana jest w przestrzeni publicznej, plany jej rozwoju prezentowane są właśnie w postaci JEPów (skrót ten rozwija się jako Java Enhancement Proposal), które to są pewnie dobrze znane czytelnikom naszych przeglądów. JSR pewnie jest czymś dużo bardziej enigmatycznym. W odróżnieniu od JEPów, których celem jest stworzenie rozwiązania technologicznego od zera, mówimy tutaj bowiem o “wyspecyfikowaniu” już istniejącego rozwiązania. Zwykle działa to w ten sposób, że rozwiązanie już istnieje, a proces standaryzacji ma na celu jego “pobłogosławienie”. Tak wyglądało to właśnie w wypadku JSR-381, które namaszcza API DeepNets na oficjalny standard. Jeżeli chcecie dowiedzieć się, jak wygląda cały proces i jakie kolejne etapy muszą przejść javowe proposale – tutaj znajdziecie przystępnie opisaną całą ścieżkę.