{"id":10927,"date":"2022-09-28T13:42:35","date_gmt":"2022-09-28T11:42:35","guid":{"rendered":"https:\/\/vived.io\/?p=10927"},"modified":"2022-09-28T13:46:55","modified_gmt":"2022-09-28T11:46:55","slug":"czy-jakarta-ee-zawalczy-z-microprofile-o-serca-tworzacych-mikroserwisy-jvm-weekly-106%ef%bf%bc","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/czy-jakarta-ee-zawalczy-z-microprofile-o-serca-tworzacych-mikroserwisy-jvm-weekly-106%ef%bf%bc\/","title":{"rendered":"Czy Jakarta EE zawalczy z Microprofile o serca tworz\u0105cych mikroserwisy? – JVM Weekly #106\ufffc"},"content":{"rendered":"\n

1. Czy Jakarta EE zawalczy z Microprofile o serca tworz\u0105cych mikroserwisy?<\/h2>\n\n\n\n

Sezonowo\u015b\u0107 wiadomo\u015bci w \u015bwiecie JVM jest niesamowita (albo i nie-tak-niesamowita, bo prawdopodobnie skorelowana z okresem wakacyjnym). Albo w spo\u0142eczno\u015bci nie dzieje si\u0119 nic (jak potrafi\u0142o by\u0107 w niekt\u00f3re lipcowe\/sierpniowe tygodnie), albo co tydzie\u0144 dostajemy wysyp nowo\u015bci – taki by\u0142 ca\u0142y wrzesie\u0144. Ot\u00f3\u017c w zesz\u0142\u0105 \u015brod\u0119 ca\u0142a edycja po\u015bwi\u0119cona by\u0142a premierze \u015bwie\u017cusie\u0144kiej JDK 19, a dzi\u015b mamy dla Was Jakart\u0119 EE 10<\/a>, b\u0119d\u0105c\u0105 zwie\u0144czenie ostatnich dw\u00f3ch lat prac. Ostatnie wi\u0119ksze wydanie (Jakarta EE 9.1) skupia\u0142o si\u0119 na dopinaniu zmian zwi\u0105zanych z przej\u015bciem na zupe\u0142nie nowy namespace, „dziesi\u0105tka” przynosi szereg du\u017cych aktualizacji.<\/p>\n\n\n\n

Je\u017celi mia\u0142bym wskaza\u0107 jedn\u0105, najwi\u0119ksz\u0105 zmian\u0119 w nowym wydaniu, wybra\u0142bym chyba pojawienie si\u0119 nowego Profilu – Core<\/a>. Czym s\u0105 profile? Kiedy\u015b mieli\u015bmy tylko jeden wariant Java EE, co by\u0142o proste, ale powodowa\u0142o problemy. Standard by\u0142 szeroki, a aby przej\u015b\u0107 certyfikacje dany serwer aplikacyjny musia\u0142 zaimplementowa\u0107 ka\u017cde nowe API, co wyd\u0142u\u017ca\u0142o czas adopcji nowych rozwi\u0105za\u0144. Dlatego te\u017c tw\u00f3rcy JEE wyr\u00f3\u017cnili dwa profile – Full i Web, gdzie ten drugi przeznaczony by\u0142 dla typowych aplikacji Webowych. <\/p>\n\n\n\n

To wszystko jednak dzia\u0142o si\u0119 w epoce, zanim zacz\u0119li\u015bmy pakowa\u0107 nasze aplikacje w pojedyncze deployowane jarki. Ta zmiana – oraz nowa generacja rozwi\u0105za\u0144 – spowodowa\u0142a konieczno\u015b\u0107 dalszego dokrojenia liczby kluczowych API wy\u0142\u0105cznie do tych przydatnych w takim use-case. Tak powsta\u0142 niezale\u017cny od Jakarty EE MicroProfile, a teraz jego konkurent(?) – oficjalny profil Core Jakarty EE. Dlaczego Jakarta EE tworzy w\u0142asne rozwi\u0105zanie zamiast dogada\u0107 si\u0119 z Microprofile? TLDR: Zwi\u0105zane jest to z elastyczno\u015bci\u0105, kt\u00f3rej tw\u00f3rcy MP \u0142akn\u0105, a kt\u00f3rej Jakarta EE nie jest za bardzo w stanie im zaoferowa\u0107<\/a>. Nie oznacza to jednak, \u017ce mi\u0119dzy projektami jest jakikolwiek konflikt – w tej chwili jednak Core Profile b\u0119dzie m\u00f3g\u0142 po prostu stanowi\u0107 baz\u0119, kt\u00f3r\u0105 MicroProfile b\u0119dzie w stanie rozbudowywa\u0107.<\/p>\n\n\n

\n
\"\"
A co b\u0119dzie w przysz\u0142o\u015bci? Zobaczymy.<\/figcaption><\/figure><\/div>\n\n\n

Przejd\u017amy teraz do nowo\u015bci w samych API. Zacznijmy od Jakarta Context and Dependency Injection (CDI) 4.0. Od lat trwa proces nieustannego odchudzania korporacyjnej Javy, i w tym kierunku zmierzy\u0142 te\u017c popularny CDI. Jego struktura w og\u00f3le zrobi\u0142a si\u0119 mocno skomplikowana. Opr\u00f3cz podzia\u0142u na wersje SE (dla standardowej Javy, u\u017cywana min. przez Helidon) i EE, teraz pojawi\u0142y si\u0119 kolejne warianty \u2013 CDI Full oraz CDI Lite. Ten ostatni zawiera wy\u0142\u0105cznie najbardziej kluczowe aspekty CDI. Zosta\u0142 zaprojektowany w celu wsparcia potrzeby popularnych bibliotek, takich jak Dagger czy Guice, pomijaj\u0105c bardziej zaawansowane funkcjonalno\u015bci powi\u0105zane z cyklem \u017cycia wstrzykiwanych zale\u017cno\u015bci. Podejrzewam, \u017ce dla wi\u0119kszo\u015bci z naszych czytelnik\u00f3w CDI Lite b\u0119dzie docelowym rozwi\u0105zaniem \u2013 to w\u0142a\u015bnie on b\u0119dzie u\u017cywany przez popularne frameworki jak Quarkus czy Micronaut. Je\u017celi jeste\u015bcie ciekawi szerszego opracowania, bardzo dobre znajdziecie na The Server Side<\/a>.<\/p>\n\n\n

\n
\"\"
Odchudzanie Jakarty EE trwa.<\/figcaption><\/figure><\/div>\n\n\n

U\u017cytkownicy CDI uciesz\u0105 si\u0119 r\u00f3wnie\u017c z kolejnej interesuj\u0105cej zmiany, jak\u0105 przynosi Jakarta Concurrency 3.0. Ot\u00f3\u017c wprowadza ona kompatybiln\u0105 z CDI 4.0 wersj\u0119 adnotacji @Asynchronous, do tej pory wsp\u00f3\u0142pracuj\u0105cej wy\u0142\u0105cznie z EJB. Wynikiem metod oznaczonych za pomoc\u0105 @Asynchronous musi by\u0107 ComputableFuture<\/code>, a dodatkowo mamy mo\u017cliwo\u015b\u0107 sprecyzowania thread poola, na kt\u00f3rym odbywa\u0107 maj\u0105 si\u0119 wykonania. Stanowi to krok do przodu w stosunku do wariantu starych Enterprise Java Beans, kt\u00f3ry wymusza\u0142 u\u017cycie puli zdefiniowanej przez serwer aplikacyjny.<\/p>\n\n\n\n

Schodz\u0105c troch\u0119 z tematu zarz\u0105dzania zale\u017cno\u015bciami – Jakarta Security w wersji 3.0 przynosi d\u0142ugo oczekiwane wsparcie OpenID Connect, co z pewno\u015bci\u0105 ucieszy tw\u00f3rc\u00f3w aplikacji u\u017cywaj\u0105cych zewn\u0119trznych dostawc\u00f3w to\u017csamo\u015bci do autoryzacji u\u017cytkownik\u00f3w. Jakarta RESTful Web Services 3.1 to za\u015b Java SE Bootstrap API – czyli mo\u017cliwo\u015b\u0107 u\u017cywania serwis\u00f3w Restowych np. w testach. Po latach te\u017c doczekali\u015bmy si\u0119 te\u017c oficjalnego wsparcia UUID jako typu danych w Jakarta Persistent API, jak teraz rozwija si\u0119 powszechnie znany skr\u00f3t JPA.<\/p>\n\n\n\n

Ca\u0142o\u015b\u0107 dope\u0142nia aktualizacja Jakarta Faces, kt\u00f3rych czwarta wersja ukazuje si\u0119 w ramach JEE 10. Najwi\u0119ksz\u0105 zmian\u0105 jest ucieczka od EJB w stron\u0119 wspomnianego ju\u017c CDI. U\u0142atwione ma by\u0107 te\u017c tworzenie widok\u00f3w HTML-owych bezpo\u015brednio z kodu javowego – powsta\u0142o do tego dedykowane API. Czy to wystarczy, aby odzyska\u0107 serce spo\u0142eczno\u015bci, kt\u00f3ra wyra\u017anie straci\u0142a serce do projektu? Ostatnio w sieci pojawi\u0142o si\u0119 kilka<\/a> pozytywnych<\/a> opinii na temat drogi, kt\u00f3r\u0105 przeszed\u0142 projekt, ale z mojej perspektywy raczej nawet powr\u00f3t mody na Server-Side Rendering nie wystarczy, aby\u015bmy zaobserwowali masow\u0105 adopcj\u0119.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Jakarta Faces od pocz\u0105tku pozycjonowa\u0142a si\u0119 jako rozwi\u0105zanie, kt\u00f3re pozwala programistom Java tworzy\u0107 aplikacje full-stackowe, nawet bez bieg\u0142o\u015bci w JavaScripcie. Dlatego na koniec sekcji Jakartowej nie m\u00f3g\u0142bym nie wspomnie\u0107 o apelu, kt\u00f3ry Ryan Dahl – tw\u00f3rca Node.js – wystosowa\u0142 w kierunku Oracle<\/a>. Okazuje si\u0119, \u017ce ze wzgl\u0119du na zawi\u0142o\u015bci historyczne i prawne, to w\u0142a\u015bnie Oracle posiada prawa do nazwy (trademark) JavaScript, co jest bardzo nie w smak spo\u0142eczno\u015bci projektu. Wskazywane s\u0105 dok\u0142adnie te same ryzyka, kt\u00f3re zmusi\u0142y spo\u0142eczno\u015b\u0107 do d\u0142ugoletniej migracji z brandu Java EE na Jakarta EE. Wskazywane jest, \u017ce kiedy\u015b Oracle mo\u017ce postanowi\u0107 swojego trademarku broni\u0107, a ju\u017c dzisiaj nazwa jest czym\u015b mocno toksycznym dla wielu podmiot\u00f3w, boj\u0105cych si\u0119 nadepn\u0105\u0107 korporacji Larry’ego Ellisona.<\/p>\n\n\n

\n
\"\"
JakartaScript potwierdzona!<\/figcaption><\/figure><\/div>\n\n\n

\u0179r\u00f3d\u0142a<\/h3>\n\n\n\n