Jakarta EE

Geneza i powstanie J2EE (1999)

Rozwój J2EE poprzedzało powstawanie osobnych technologii serwerowych Javy. W latach 90. dynamiczne strony internetowe tworzono m.in. przy użyciu skryptów CGI. Serwlety umożliwiły obsługę żądań internetowych w środowisku Javy, a technologia JavaServer Pages (JSP) ułatwiła przygotowywanie generowanych po stronie serwera stron WWW. Równolegle rozwijano JDBC do komunikacji z bazami danych, Enterprise JavaBeans (EJB) do budowy komponentów logiki biznesowej oraz interfejsy do transakcji i komunikacji pomiędzy systemami.

Sun Microsystems przygotowało platformę Java 2 Platform, Enterprise Edition (J2EE), aby połączyć te mechanizmy w spójny zestaw specyfikacji i ujednolicić model uruchamiania aplikacji wielowarstwowych. Pierwsze wydanie, J2EE 1.2, zostało ogłoszone w grudniu 1999 roku. Obejmowało m.in. serwlety, JSP i EJB, a jego ważnym założeniem była możliwość łączenia aplikacji internetowych z istniejącymi systemami przedsiębiorstw.

J2EE oddzielało kod aplikacji od części jej infrastruktury. Programista mógł tworzyć serwlety obsługujące komunikację z przeglądarką, strony JSP generujące dynamiczną zawartość oraz komponenty EJB realizujące logikę biznesową. Zadania takie jak zarządzanie cyklem życia komponentów, bezpieczeństwo i koordynowanie transakcji miały być przejmowane przez tzw. kontenery udostępniane przez serwer. W założeniu miało to ułatwić przenoszenie aplikacji pomiędzy zgodnymi produktami różnych dostawców i ograniczyć zależność od ich własnych interfejsów.

Wczesny model J2EE był zorientowany na aplikacje korporacyjne podzielone na warstwy: klienta, część internetową, logikę biznesową i dostęp do systemów zaplecza. Wykorzystywał m.in. JDBC do pracy z bazami danych, JNDI do wyszukiwania zasobów oraz Java Transaction API (JTA) do transakcji. Ważną rolę odgrywały pliki konfiguracyjne XML, określające sposób wdrożenia komponentów na serwerze.

Standaryzacja i zgodność implementacji

J2EE definiowało nie tylko poszczególne API, lecz także sposób ich współdziałania. Wspólne reguły obejmowały wyszukiwanie zasobów przez JNDI, konfigurowanie komponentów za pomocą deskryptorów wdrożenia oraz pakowanie aplikacji w postaci archiwów. Miało to umożliwiać uruchamianie oprogramowania na serwerach różnych producentów, pod warunkiem zgodności z wymaganiami platformy. Poszczególne specyfikacje rozwijano w ramach Java Community Process, a kompletne środowiska weryfikowano z użyciem testów zgodności.

Rozwój J2EE 1.3 i 1.4 (2001–2003)

J2EE 1.3, ukończone we wrześniu 2001 roku, rozbudowało możliwości integracji z zewnętrznymi systemami przedsiębiorstw. Wprowadzono wymaganie obsługi Java Message Service (JMS) i mechanizmy Connector Architecture pozwalające tworzyć adaptery do systemów zaplecza. Rozszerzono także EJB, m.in. o komponenty message-driven beans służące do asynchronicznej obsługi komunikatów, interfejsy lokalne oraz nowy model utrwalania danych zarządzany przez kontener. Wprowadzono ponadto obsługę przetwarzania XML poprzez JAXP.

J2EE 1.4 z 2003 roku położyło nacisk na usługi sieciowe wykorzystujące XML. Do platformy włączono m.in. JAX-RPC (wywołania zdalne oparte na XML) oraz SAAJ (obsługę komunikatów SOAP), a specyfikacja określała sposób udostępniania usług sieciowych przez komponenty aplikacji. Rozwijano także narzędzia wdrażania i zarządzania aplikacjami oraz standardowe mechanizmy autoryzacji.

Wczesne wydania J2EE oferowały bogatą funkcjonalność, lecz opracowywanie aplikacji mogło wymagać definiowania wielu interfejsów, klas pomocniczych i deskryptorów wdrożenia. Szczególnie widoczne było to w starszych modelach komponentów EJB. Uproszczenie tych mechanizmów stało się jednym z głównych celów kolejnej generacji platformy.

Krytyka złożoności i rozwój alternatywnych modeli

W pierwszej połowie lat 2000. część programistów kwestionowała złożoność tworzenia aplikacji opartych na EJB 2.x. Krytyka dotyczyła m.in. konieczności przygotowywania licznych interfejsów i plików konfiguracyjnych dla stosunkowo prostych komponentów. Rod Johnson, późniejszy twórca Spring Framework, opisywał te trudności na podstawie swoich doświadczeń z aplikacjami J2EE. Framework Spring, rozwijany niezależnie od specyfikacji J2EE, oferował m.in. wstrzykiwanie zależności oraz możliwość korzystania ze zwykłych obiektów Javy jako komponentów aplikacji.

Kolejne wersje standardu i rozwijane poza nim frameworki przyjmowały różne sposoby upraszczania aplikacji korporacyjnych. Zmiany w EJB 3.0 i wprowadzenie JPA w Java EE 5 ograniczyły liczbę wymaganych klas pomocniczych i deskryptorów XML, pozostawiając zarządzanie transakcjami czy bezpieczeństwem po stronie kontenera.

Java EE 5: uproszczenie modelu programowania (2006)

W maju 2006 roku ukazała się Java EE 5. Jednocześnie zrezygnowano z nazwy J2EE na rzecz Java Platform, Enterprise Edition (Java EE), usuwając cyfrę „2” z nazwy platformy. Jednym z zasadniczych celów wydania było zmniejszenie ilości kodu i konfiguracji potrzebnych do tworzenia aplikacji.

Java EE 5 szerzej wykorzystało adnotacje wprowadzone do języka Java w wersji 5. Dzięki nim wiele informacji o komponentach, zależnościach i konfiguracji mogło być umieszczanych bezpośrednio w kodzie źródłowym, a nie wyłącznie w plikach XML. Uproszczono EJB w wersji 3.0, wprowadzono Java Persistence API (JPA) dla mapowania obiektów na dane relacyjne oraz rozszerzono użycie wstrzykiwania zależności. Rozwijano także JavaServer Faces (JSF) i obsługę usług sieciowych JAX-WS.

Zmiany oznaczały odejście od części obowiązkowych wzorców charakterystycznych dla EJB 2.x. W wielu przypadkach komponent biznesowy mógł być zwykłą klasą Java opatrzoną odpowiednimi adnotacjami, a kontener zapewniał pozostałe usługi infrastrukturalne.

Java EE 6, 7 i 8 (2009–2017)

W Java EE 6 z grudnia 2009 roku wprowadzono Contexts and Dependency Injection (CDI), ujednolicające wstrzykiwanie zależności i zarządzanie kontekstami komponentów. Dodano mechanizm walidacji Bean Validation oraz ustandaryzowano w ramach platformy budowanie usług REST za pomocą JAX-RS. Po raz pierwszy wydzielono także Web Profile, obejmujący podzbiór technologii potrzebnych do tworzenia aplikacji internetowych bez konieczności implementowania całego standardu.

Java EE 7, zatwierdzone w maju 2013 roku, rozszerzyło obsługę technologii internetowych, m.in. o interfejsy API do komunikacji przez WebSocket, przetwarzania JSON i korzystania z klienta REST. Dodano mechanizmy przetwarzania wsadowego (Batch Applications) oraz zarządzanej współbieżności (Concurrency Utilities). Uproszczono także JMS w wersji 2.0 i rozbudowano CDI.

Ostatnim wydaniem platformy przygotowanym pod nazwą Java EE była Java EE 8 z 2017 roku. Wprowadziła ona interfejs JSON-B, mapujący dane JSON na obiekty Java, obsługę HTTP/2 w Servlet 4.0 i nowy interfejs API bezpieczeństwa Java EE Security. Rozszerzono również możliwości obsługi zdarzeń w CDI oraz usług REST, m.in. o server-sent events.

Przekazanie projektu do Eclipse Foundation i zmiana nazwy (2017–2019)

Po przejęciu Sun Microsystems przez Oracle w 2010 roku rozwój Java EE pozostawał w ramach procesu Java Community Process (JCP). We wrześniu 2017 roku Oracle ogłosiło zamiar przekazania rozwoju platformy organizacji Eclipse Foundation, z którą związano projekt Eclipse Enterprise for Java (EE4J). Przeniesienie obejmowało projekty implementacyjne, specyfikacje i zestawy testów zgodności.

W lutym 2018 roku, po głosowaniu społeczności, ogłoszono nową nazwę Jakarta EE. Nawiązywała ona do wcześniejszego projektu Apache Jakarta, rozwijanego w Apache Software Foundation, która zgodziła się na ponowne użycie nazwy. W głosowaniu uczestniczyło prawie 7000 osób, z których ponad 64% opowiedziało się za nazwą Jakarta EE. Litery „EE” w nowej nazwie nie stanowią oficjalnego rozwinięcia „Enterprise Edition”, lecz są elementem nazwy własnej, co wyjaśnił dyrektor wykonawczy Eclipse Foundation Mike Milinkovich.

Pierwszą wersją wydaną przez Eclipse Foundation jako Jakarta EE 8 było wydanie z 10 września 2019 roku. Zachowało ono zgodność interfejsów API z Java EE 8 i stanowiło punkt wyjścia do dalszego rozwoju projektu w nowym modelu organizacyjnym.

Jednym z celów zmian organizacyjnych była większa otwartość procesu standaryzacyjnego i szybszy rozwój specyfikacji. W dyskusjach nad dalszym kierunkiem platformy podkreślano znaczenie aplikacji uruchamianych w chmurze i architektury mikrousług. Rozwijany również w Eclipse Foundation projekt Eclipse MicroProfile koncentrował się na API dla takich zastosowań, pozostając odrębną inicjatywą wobec samej specyfikacji Jakarta EE.

Zmiana przestrzeni nazw: Jakarta EE 9 i 9.1 (2020–2021)

Jedną z najważniejszych konsekwencji przekazania platformy były ograniczenia dotyczące użycia znaków towarowych i dotychczasowej przestrzeni nazw API. Po uzgodnieniach z Oracle społeczność projektu zdecydowała o przeniesieniu pakietów specyfikacji Jakarta EE z przestrzeni nazw javax.* do jakarta.*. Zmianę wprowadzono w Jakarta EE 9, opublikowanej 8 grudnia 2020 roku.

Modyfikacja dotyczyła m.in. nazw pakietów w kodzie źródłowym, deklaracji zależności, adnotacji, plików konfiguracji oraz bibliotek. Przykładowo klasa javax.servlet.http.HttpServlet z wcześniejszych wydań odpowiada klasie jakarta.servlet.http.HttpServlet w nowszych. Nie oznaczało to przeniesienia wszystkich pakietów zaczynających się od javax w całym ekosystemie Java, lecz tych należących do specyfikacji Jakarta EE. Jakarta EE 9 nie zachowało bezpośredniej zgodności kodu źródłowego ani kodu binarnego z poprzednimi wydaniami w zakresie zmienionych API.

Zmiana przestrzeni nazw wymagała aktualizacji importów klas i zależności bibliotek w aplikacjach przechodzących na nowe API. W przypadku starszego oprogramowania stosowano również narzędzia przekształcające kod lub pliki klas. Zgodność aplikacji zależy od użytych specyfikacji i możliwości środowiska uruchomieniowego, dlatego przejście na nowszą wersję serwera nie zawsze wymaga identycznego zakresu zmian.

W Jakarta EE 9.1 z maja 2021 roku rozszerzono obsługę platformy o środowisko uruchomieniowe Java SE 11, bez wprowadzania zasadniczych zmian w interfejsach API względem wersji 9.

Jakarta EE 10 i 11 (2022–2025)

Jakarta EE 10, wydane we wrześniu 2022 roku, wprowadziło istotne aktualizacje specyfikacji składowych oraz Core Profile, mniejszy zestaw interfejsów API przeznaczony do wykorzystania w lekkich środowiskach uruchomieniowych i aplikacjach opartych na mikrousługach. W tej wersji zrezygnowano także ze wsparcia Java SE 8 jako podstawy platformy.

Jakarta EE 11, ogłoszone 26 czerwca 2025 roku, dodało specyfikację Jakarta Data do definiowania warstwy dostępu do danych z wykorzystaniem interfejsów repozytoriów. Wprowadzono aktualizacje m.in. Jakarta Persistence, Validation, CDI i Concurrency, w tym obsługę wybranych zastosowań rekordów Javy i wątków wirtualnych w środowiskach opartych na Java 21. Minimalną wersją Java SE wymaganą przez platformę stała się Java 17. Z zestawu specyfikacji platformy usunięto Jakarta Managed Beans, Jakarta SOAP with Attachments, Jakarta XML Binding i Jakarta XML Web Services. Trzy ostatnie specyfikacje były już opcjonalne w Jakarta EE 10; ich wycofanie z platformy nie oznacza zaprzestania rozwoju samodzielnych implementacji.

Specyfikacja i środowisko uruchomieniowe

Jakarta EE nie jest pojedynczym programem ani serwerem, lecz zbiorem wymagań określających zachowanie zgodnych implementacji. Definiuje kontrakty pomiędzy komponentami aplikacji a środowiskiem uruchomieniowym, pozwalając aplikacjom korzystać z usług kontenera bez bezpośredniego implementowania mechanizmów infrastruktury. Specyfikacja nie narzuca jednego sposobu rozmieszczenia wszystkich elementów systemu: mogą one działać na pojedynczym serwerze lub na wielu maszynach.

Klasyczny model wielowarstwowy wywodzący się z J2EE wyróżnia:

• warstwę klienta – np. przeglądarkę internetową albo aplikację komunikującą się z serwerem;
• warstwę internetową – komponenty obsługujące żądania HTTP, takie jak serwlety i strony serwerowe;
• warstwę logiki biznesowej – usługi i komponenty implementujące reguły działania aplikacji, w tradycyjnym modelu często z wykorzystaniem EJB;
• warstwę systemów zaplecza – bazy danych, systemy wymiany komunikatów i inne usługi przedsiębiorstwa.

Współczesne aplikacje Jakarta EE nie muszą stosować wszystkich tych warstw jako oddzielnych programów. Mogą wykorzystywać wybrane specyfikacje w jednej aplikacji internetowej albo w zestawie usług komunikujących się przez sieć.

Kontenery i usługi infrastrukturalne

Kontener to część środowiska uruchomieniowego zapewniająca komponentom zestandaryzowane usługi. Historycznie J2EE rozróżniało m.in. kontener WWW dla serwletów i JSP oraz kontener EJB dla komponentów biznesowych. Wspólne usługi obejmowały zarządzanie cyklem życia, udostępnianie zasobów, bezpieczeństwo, transakcje i komunikację pomiędzy elementami aplikacji.

Konfiguracja tych usług może być określana deklaratywnie, m.in. przy użyciu adnotacji Java i deskryptorów wdrożenia. Dzięki temu programista może opisywać wymagane zachowanie, np. udział metody w transakcji lub ograniczenie dostępu do zasobu, bez implementowania całej obsługi tych funkcji w kodzie aplikacji.

Moduły i wdrażanie aplikacji

W modelu J2EE i Java EE komponenty pakowano do standaryzowanych archiwów. Pliki WAR (Web Application Archive) zawierają aplikacje internetowe, JAR (Java Archive) mogą zawierać m.in. komponenty biznesowe, a EAR (Enterprise Archive) służą do łączenia wielu modułów aplikacji przedsiębiorstwa. Ustawienia wdrożeniowe mogły być przechowywane w plikach XML, takich jak web.xml lub application.xml. W nowszych wydaniach wiele takich ustawień można zastąpić adnotacjami.

Warstwa internetowa i usługi sieciowe

• Jakarta Servlet (wcześniej Java Servlet) – definiuje model obsługi żądań i odpowiedzi HTTP przez komponenty serwerowe.
• Jakarta Pages (wcześniej JavaServer Pages, JSP) – pozwala tworzyć dynamiczne strony po stronie serwera z wykorzystaniem szablonów.
• Jakarta Faces (wcześniej JavaServer Faces, JSF) – definiuje model komponentowego interfejsu użytkownika dla aplikacji internetowych.
• Jakarta RESTful Web Services (wcześniej JAX-RS) – służy do budowania usług sieciowych wykorzystujących architekturę REST.
• Jakarta WebSocket – definiuje dwukierunkową komunikację pomiędzy klientem a serwerem poprzez protokół WebSocket.
• Jakarta JSON Processing i Jakarta JSON Binding – służą odpowiednio do przetwarzania dokumentów JSON i ich odwzorowywania na obiekty Javy.

Komponenty biznesowe i dane

• Jakarta Enterprise Beans (dawniej Enterprise JavaBeans, EJB) – zapewnia model komponentów biznesowych i integrację z usługami kontenera, m.in. transakcjami i bezpieczeństwem.
• Jakarta Contexts and Dependency Injection (CDI) – zarządza zależnościami pomiędzy komponentami oraz ich kontekstami i cyklem życia.
• Jakarta Persistence (dawniej JPA) – standaryzuje mapowanie obiektowo-relacyjne i dostęp do danych przechowywanych w relacyjnych bazach danych.
• Jakarta Data – określa interfejsy repozytoriów i mechanizmy upraszczające tworzenie warstwy dostępu do danych.
• Jakarta Validation – definiuje deklaratywne sprawdzanie poprawności danych i obiektów.
• Jakarta Transactions (dawniej JTA) – określa sposoby zarządzania transakcjami.

Komunikacja i usługi systemowe

• Jakarta Messaging (dawniej JMS) – umożliwia wymianę komunikatów i komunikację asynchroniczną.
• Jakarta Concurrency – udostępnia zarządzane przez środowisko wykonawcze mechanizmy współbieżnego wykonywania zadań.
• Jakarta Security, Jakarta Authentication i Jakarta Authorization – definiują elementy uwierzytelniania, autoryzacji i zabezpieczania zasobów.
• Jakarta Connectors – umożliwia integrację z zewnętrznymi systemami przedsiębiorstwa przy użyciu adapterów zasobów.
• Jakarta Mail – udostępnia funkcje obsługi poczty elektronicznej.
• Jakarta Batch – określa model uruchamiania zadań wsadowych.

Nie wszystkie wymienione interfejsy są wymagane w każdym profilu Jakarta EE. Część specyfikacji jest używana również samodzielnie, poza kompletnym serwerem aplikacji.