Migracja z Java EE do Jakarta EE — rozwiewamy wątpliwości 

Przychodzi taki czas w trakcie rozwoju biznesu, że musimy przeprowadzić migrację aplikacji. Szczególnie jest to istotne w produktach korporacyjnych, które działają w oparciu o licencje lub umowy SLA (Service-Level Agreement).  Aby zrealizować te wymagania, może być wymagana aktualizacja z Java EE do Jakarta. Czy jesteś na to gotowy? 

Zastanówmy się, co pociąga za sobą ta zmiana i czy jest to rozsądne posunięcie dla twoich projektów rozwojowych lub celów organizacyjnych. 

Krótka historia Java EE i Jakarta EE 

Aby w pełni zrozumieć znaczenie Jakarta EE, konieczne jest zrozumienie początków jej poprzedniczki, Java EE. Opracowana przez Sun Microsystems (później przejęta przez Oracle), Java EE lub Java Enterprise Edition, była szeroko przyjętą platformą do tworzenia  skalowalnych i bezpiecznych aplikacji korporacyjnych. Rozszerzyła ona możliwości Java Standard Edition (Java SE) o kompleksowy zestaw interfejsów API i specyfikacji dostosowanych do rozwoju po stronie serwera.  

Z biegiem lat Java EE stała się podstawą wielu systemów o znaczeniu krytycznym, znanych ze swojej stabilności, dojrzałości i niezawodności. Jednak W 2017 roku Oracle ogłosiło jednak, że przeniesie kontrolę nad Java EE do Eclipse Foundation, co było ogromnym krokiem, który doprowadził do powstania Jakarta EE.  

Zmiana ta nie była jedynie rebrandingiem, ale początkiem nowej ery. Obecnie branża rozwija się w kierunku architektury natywnej dla chmury, mikro-usług i konteneryzacji, dlatego Jakarta EE ewoluuje w tym kierunku, jednocześnie stanowiąc stabilną platformę dla istniejących aplikacji Java EE.   

Ilustracja poniżej pokazuje, w jaki sposób platformy Jakarta EE i Java SE są ze sobą połączone. Platforma Java SE określa standardy dla Java SDK, JRE, JVM i JCL. Jakarta EE rozszerza Java SE, definiując zbiór interfejsów API dostosowanych do tworzenia aplikacji korporacyjnych. 

Kluczowe różnice między Java EE i Jakarta EE 

Chociaż Jakarta EE i Java EE mają wspólne dziedzictwo i są zbudowane na tych samych zasadach, istnieją pewne kluczowe różnice między tymi dwiema platformami.  

Zmiana w zarządzaniu i własności 

Java SE i Java EE była przede wszystkim zarządzana przez Oracle, a decyzje i aktualizacje pochodziły od scentralizowanego organu. W pewnym momencie Java EE została wycofana z oferty Oracle, a jej specyfikacje zostały przeniesione do Eclipse Foundation. Jednak Oracle zastrzegło sobie używanie wyrażenia Java. Od tego czasu Oracle koncentruje się na Java SE. 

W przeciwieństwie do tego, Jakarta EE jest obecnie zarządzana przez Eclipse Foundation, która stosuje podejście bardziej oparte na społeczności. Zarządza m.in. takimi zależnościami jak Hibernate (JPA), Tomcat (serwlety) itd. Ta zmiana w zarządzaniu pozwala na większą przejrzystość, współpracę i integrację w procesie rozwoju.  

Jakarta EE stanowi niejako łącznik między tradycyjnymi i nowoczesnymi technologiami, umożliwiając organizacjom wdrażanie nowych osiągnięć technologicznych przy jednoczesnym zachowaniu obecnych inwestycji w aplikacje i infrastrukturę. 

Konwencja nazewnictwa 

Java EE wykorzystywała monolityczny schemat nazewnictwa pakietów, w którym wszystkie specyfikacje były poprzedzone przedrostkiem „javax”. Ta konwencja nazewnictwa odzwierciedlała scentralizowaną kontrolę i własność platformy.  

Z drugiej strony, Jakarta EE przyjmuje bardziej modułowe i rozszerzalne podejście. Interfejsy API i specyfikacje są teraz poprzedzone przedrostkiem „jakarta”, co odzwierciedla społecznościowy i open-source’owy charakter platformy. To modułowe podejście pozwala na łatwiejszą integrację z innymi projektami open-source i promuje interoperacyjność.  

Główną zmianą była nazwa usługi, ale nie klas z nią związanych. Tak więc można było znać wcześniejsze nazewnictwo usługi przesyłania wiadomości Java JMS (Java Message Service), która została przekształcona w usługę przesyłania wiadomości Jakarta (Jakarta Message service). Podobnie specyfikacje serwletów Java (Java Servlet Specs) są teraz specyfikacjami serwletów Jakarta (Jakarta Servlet Specs). JDBC było kiedyś łącznością z bazą danych Java, teraz jest to łączność z bazą danych Jakarta. 

Rozwój w chmurze i architektura mikroserwisów 

Podczas gdy Java EE zapewniała wsparcie dla obliczeń rozproszonych i usług sieciowych, Jakarta EE idzie o krok dalej, przyjmując zasady natywne dla chmury, takie jak konteneryzacja i orkiestracja. Ta zmiana umożliwia programistom tworzenie skalowalnych, odpornych i przenośnych aplikacji, które mogą płynnie działać w nowoczesnych środowiskach chmurowych.  

Podsumowanie różnic między Java EE vs Jakarta EE 

Korzyści płynące z wykorzystania platformy Jakarta EE  

Jakarta EE jest standardem, z którym współpracuje wiele istniejących rozwiązań. . Produkty, które być może znasz – takie jak Jetty, Tomcat, Jersey i Spring – wszystkie opierają się na technologiach Jakarta EE.  Na przykład Apache Tomcat implementuje cztery specyfikacje Jakarta EE, Spring Boot osadza Apache Tomcat, Eclipse Jetty lub Undertow jako środowisko uruchomieniowe. Dobrym przykładem technologii, które również opierają się na Jakarta EE w swoich natywnych aplikacjach Java dla przedsiębiorstw w chmurze, są Eclipse Jetty, Eclipse IDE, MicroProfile i inne frameworki branżowe, które implementują MicroProfile (source: jakarta.ee) 

Przejście z Java EE na Jakarta EE niesie ze sobą szereg korzyści dla programistów Java. 

1. Bardziej otwarty procesu rozwoju.  

Dzięki temu, że jest to projekt open-source deweloperzy mają wpływ na kierunek rozwoju platformy i mogą aktywnie przyczyniać się do jej wzrostu i ewolucji.  

2. Integracja z innymi projektami open-source.  

Modułowa natura platformy pozwala programistom mieszać i dopasowywać komponenty od różnych dostawców, frameworków i bibliotek, tworząc bardziej elastyczne i konfigurowalne środowisko programistyczne.  

3. Kompatybilność z Java EE.  

Istniejące aplikacje Java EE można bardzo łatwo migrować do Jakarta EE koncentrując się na zachowaniu kompatybilności. Pozwala to firmom wykorzystać istniejące inwestycje w aplikacje i infrastrukturę Java EE, jednocześnie korzystając z nowych funkcji i ulepszeń oferowanych przez Jakarta EE.  

4. Wsparcie długoterminowe 

Fundacja Eclipse, która nadzoruje platformę Jakarta EE, zapewnia długoterminowe wsparcie dla swoich wydań. Dzięki temu użytkownicy Jakarta EE mogą otrzymywać aktualizacje, poprawki bezpieczeństwa i poprawki błędów przez określony czas, zazwyczaj kilka lat po wydaniu. 

5. Mniej restrykcyjna licencja 

 W ramach Eclipse Foundation, Jakarta EE przyjęła bardziej liberalną strukturę licencji dla swoich specyfikacji, znaną jako „Eclipse Foundation Specification License”. Licencja ta jest mniej restrykcyjna w porównaniu z poprzednimi licencjami Java Community Process (JCP) prowadzonymi przez Oracle, co pozwala na łatwiejszą kompatybilność i udział w rozwoju technologii Jakarta EE. 

6. Modularyzacja i kontenery 

Jakarta EE obejmuje architekturę modułową, pozwalając na tworzenie lżejszych i bardziej wydajnych aplikacji poprzez wybór tylko wymaganych komponentów. Takie podejście umożliwiają szybsze uruchamianie i lepsze wykorzystanie zasobów. 

Migracja aplikacji do Jakarta EE – na co zwracać uwagę? 

 Jakarta EE w wersji 10 została wydana 13 września 2022 roku jednocześnie będąc wspieraną przez Java SE 1 i Java SE 11. Rodzi się więc pytanie, jakie wyzwania stoją przed programistami, jeśli chodzi o migrację własnych aplikacji?  

Migracja do nowych nazw pakietów 

W takich przypadkach jest się oczywiście w dużym stopniu zależnym od konkretnych planów migracji poszczególnych projektów. Z reguły nie jest to trudne zadanie, ponieważ chodzi o nazwy więc w najprostszym przypadku zmiana odbywa się poprzez proste wyszukiwanie i zamianę. Oczywiście wymaga to jeszcze dostosowania wersji API w pom.xml i ewentualnej zmiany przestrzeni nazw w plikach XML. Dużym ułatwieniem w procesie migracji jest skorzystanie z IntelliJ, który jak wskazano na stronie JetBrains, mocno automatyzuje ten proces.  

Kompatybilność 

Większe wyzwanie pojawia się w przypadku ustaleniu poziomu kompatybilności bibliotek i frameworków. Podczas gdy Jakarta EE zachowuje wsteczną kompatybilność, w Java EE, mogą występować pewne różnice w zachowaniu i implementacji. Więcej na temat roli kompatybilności Jakarta EE z licznymi narzędziami można znaleźć w oficjalnej dokumentacji. 

Wiele projektów korzysta z całej gamy innych frameworków lub bibliotek, które są spakowane w ich własnej aplikacji. Przynajmniej w niektórych przypadkach używają one również interfejsu API Java EE lub Jakarta EE i dlatego dotyka ich problem migracji. Interfejsy takie jak na przykład javax.servlet.Servlet lub javax.servlet.Filter mają ogromne znaczenie dla wielu bibliotek open source. Ważne jest, aby dokładnie przetestować i zweryfikować migrowane aplikacje, aby upewnić się, że działają zgodnie z oczekiwaniami. 

Jest to istotne, ponieważ nie wszyscy użytkownicy migrują na nową wersję platformy w tym samym czasie, co wymaga obsługiwania wtedy zarówno starych, jak i nowych nazwy pakietów przez co najmniej pewien okres czasu, a można to rozwiązać jedynie poprzez równoległe utrzymywanie dwóch gałęzi programistycznych.  

Ocena infrastruktury 

Ponadto kluczowe znaczenie ma ocena wpływu migracji na ogólną architekturę i infrastrukturę. Migracja do Jakarta EE może wymagać aktualizacji podstawowych struktur, takich jak serwery aplikacji, bazy danych i oprogramowanie pośredniczące. Ważne jest, aby ocenić kompatybilność tych komponentów z Jakarta EE i zaplanować wszelkie niezbędne aktualizacje lub zmiany. Holistyczne podejście do migracji zapewnia, że wszystkie aspekty stosu aplikacji są brane pod uwagę i uwzględniane.  

Narzędzia i zasoby dla rozwoju Jakarta  

Aby wesprzeć programistów w przejściu na Jakarta EE, dostępna jest szeroka gama narzędzi i zasobów. Fundacja Eclipse, organ zarządzający Jakarta EE, zapewnia kompleksowy zestaw narzędzi i ram, które upraszczają proces rozwoju.  

Oprócz implementacji referencyjnej istnieje kilka IDE (zintegrowanych środowisk programistycznych), które oferują wsparcie dla rozwoju Jakarta EE – Eclipse IDE, IntelliJ,  IDEA i NetBeans to niektóre z popularnych IDE, które zapewniają takie funkcje, jak uzupełnianie kodu, debugowanie i wsparcie wdrażania dla projektów Jakarta EE. 

Ekosystem Jakarta EE obejmuje również szeroką gamę bibliotek, frameworków i rozszerzeń, które mogą usprawnić proces rozwoju. Frameworki kompatybilne z Jakarta EE, takie jak Spring, Hibernate i Apache Tomcat, zapewniają dodatkową funkcjonalność i upraszczają typowe zadania, takie jak wstrzykiwanie zależności, trwałość i tworzenie stron internetowych. Struktury te posiadają obszerną dokumentację i wsparcie społeczności, co ułatwia programistom rozpoczęcie pracy i wykorzystanie ich możliwości.  

Firmy, które z sukcesem przeprowadziły migrację do Jakarta EE  

Kilka firm już wdrożyło Jakarta EE do swojego rozwoju Java dla przedsiębiorstw. Jednym z takich przykładów jest IBM, globalna firma technologiczna oferująca szeroką gamę oprogramowania i usług. IBM od dawna wspiera Java EE i wniósł znaczący wkład w rozwój platformy. Wraz z przejściem na Jakarta EE, IBM nadal aktywnie przyczynia się do rozwoju społeczności i wykorzystuje Jakarta EE w swoich aplikacjach klasy korporacyjnej.  

Innym przykładem jest Red Hat, wiodący dostawca rozwiązań open-source. Red Hat jest silnym orędownikiem technologii open-source i odegrał kluczową rolę w rozwoju Jakarta EE. Oferuje szereg produktów i usług wspierających Jakarta EE, w tym swój flagowy produkt Red Hat OpenShift, platformę kontenerową opartą na Kubernetes. Zaangażowanie Red Hat w zasady open source dobrze współgra z celami Jakarta EE, czyniąc ich naturalnym partnerem w ekosystemie.   

Dla klienta z branży logistycznej programiści VM.PL stworzyli projekt kompletnego systemu magazynowego zajmującego się przyjmowaniem towarów, obsługą zamówień i stanów magazynowych. Jednym z wyzwań była integracja systemu informatycznego z istniejącym rozwiązaniem legacy. Od zespołu VM.PL wymagało to również umiejętności dostosowania nowego oprogramowania do infrastruktury i zapewnienie bezproblemowej migracji danych. Ostatecznie w 2022 udało się z sukcesem przeprowadzić migrację do Spring Boot 3.0, która wiązała się też z migracją pakietów do Jakarta EE. 

Jakie perspektywy na przyszłość stoją przed Jakarta EE?  

Przyszłość Jakarta EE wygląda obiecująco, ponieważ cały czas rozwija się w zakresie ulepszania swojej platformy. Co więcej społeczność Jakarta EE aktywnie pracuje nad nowymi specyfikacjami, interfejsami API i narzędziami, które zaspokajają zmieniające się potrzeby rozwoju Java dla przedsiębiorstw. Do niektórych kierunków rozwoju należy: 

• Rozwój natywny dla chmury. Platforma jest ulepszana, aby lepiej wspierać konteneryzację, mikrousługi i architektury natywne dla chmury. Obejmuje to ulepszoną integrację z platformami orkiestracji kontenerów, takimi jak Kubernetes, a także wsparcie dla natywnych dla chmury wzorców i najlepszych praktyk.  
• Integracja nowych technologii, takich jak sztuczna inteligencja (AI) i uczenie maszynowe (ML) z Jakarta EE. Społeczność Jakarta EE opracowuje interfejsy API i frameworki które upraszczają integrację możliwości AI i ML z aplikacjami Jakarta EE. 
• Produktywność programistów i łatwość użytkowania. Podejmowane są wysiłki w celu uproszczenia procesu rozwoju, zmniejszenia ilości standardowego kodu oraz zapewnienia intuicyjnych interfejsów API i narzędzi.  

Czy przeprowadzisz migrację z Java EE do Jakarta EE w swoim przedsiębiorstwie? 

Jak już wspomnieliśmy w artykule migracja do Jakarta EE to duża szansa na przyszłościowy rozwój aplikacji korporacyjnych. To, kiedy i w jaki sposób ją przeprowadzić z pewnością będzie uzależnione od konkretnych potrzeb, kierunku strategicznego i zasobów firmy.   

Jednak jak wspomina Mike Milinkovich, dyrektor wykonawczy Fundacji  Eclipse:

„Jakarta EE zapewnia Twojemu przedsiębiorstwu dwie strategiczne korzyści: ścieżkę rozwoju dla istniejących inwestycji w kod aplikacji Java EE obsługujący Twoją firmę oraz świetlaną przyszłość dla wykwalifikowanych programistów Java zatrudnionych w Twoim zespole”   

Jeśli rozważasz przejście z Java EE na Jakarta EE zachęcamy do kontaktu z doświadczonymi specjalistami Java. Chętnie więcej opowiedzą w jaki sposób możesz płynnie przejść na Jakarta EE, mając pewność, że Twoje aplikacje korporacyjne będą nadążać za zmieniającym się krajobrazem technologicznym i biznesowym.