Jakarta EE

Jakarta EE jest najnowszą wersją platformy, która standaryzuje najpopularniejsze technologie wykorzystywane do tworzenia aplikacji biznesowych w Javie. Dawniej była ona rozwijana jako Java EE, jednak w 2019 roku firma Oracle przekazała ją pod skrzydła fundacji Eclipse.

Czym jest Jakarta EE

Java EE, ani Jakarta EE nie wnosi żadnych dodatkowych konstrukcji do samego języka (np. pętli, struktur sterujących, czy słów kluczowych), jest to jedynie zbiór specyfikacji odpowiedzialnych np. za komunikację z bazą danych, łączność sieciową, czy też wstrzykiwanie zależności. Specyfikację należy rozumieć jako zbiór interfejsów, klas abstrakcyjnych, czy typów wyliczeniowych, oraz dokument opisujący ich zachowanie. Następnie firmy lub organizacje mogą podjąć się implementacji danej specyfikacji i dostarczyć takie rozwiązanie do wykorzystania przez ogół programistów.

W skład platformy wchodzi kilkadziesiąt specyfikacji, m.in.:

• Jakarta Servlet (komunikacja sieciowa),
• Jakarta ServerPages (silnik szablonów wykorzystywany w aplikacjach z widokami generowanymi po stronie serwera),
• Jakarta JSON Processing (mapowanie obiektów do formatu JSON i odwrotnie),
• Jakarta Bean Validation (walidacja danych).
• Jakarta Persistence (mapowanie obiektowo relacyjne, komunikacja z bazami danych).

Pełną listę można znaleźć na stronie fundacji Eclipse.

Serwery aplikacji

Istnieje wiele serwerów, które są kompatybilne z platformą Java EE. Są to m.in. Glassfish, czyli referencyjna implementacja, Wildfly od firmy RedHat, czy OpenLiberty od IBM. W większości przypadków aplikacje nie wykorzystują wszystkich specyfikacji wchodzących w skład platformy, a jedynie ich podzbiór. Z tego powodu największą popularnością cieszą się takie rozwiązania jak Apache Tomcat, czy Jetty od fundacji Eclipse, czyli serwery, które dostarczają jedynie implementację serwletów - specyfikacji do tworzenia aplikacji webowych, wykorzystujących komunikację przez HTTP. Kontenery serwletów stanowią też podstawę większości aplikacji webowych tworzonych z wykorzystaniem frameworka Spring. Stąd dominująca pozycja serwera Tomcat.

W przypadku Jakarty EE referencyjną implementacją jest Glassfish 6, ale inne rozwiązania są do niej dostosowywane. W przypadku serwera Tomcat należy skorzystać co najmniej z wersji 10.

Zmiana przestrzeni nazw

Pierwsza wersja platformy Jakarta EE była oznaczona numerem 8 i pojawiła się w 2019 roku. Była ona bezpośrednią kontynuacją platformy Java EE 8 i zachowywała z nią pełną kompatybilność, tzn aplikacje napisane w Jakarcie EE 8 można było uruchamiać na serwerach zgodnych z Javą EE 8. Jakarta EE 8 nie wniosła żadnych zmian do platformy, specyfikacje zostały jedynie przeniesiona na GitHuba. Po oddaniu Jakarty EE do fundacji Eclipse pojawiły się pewne problemy natury prawnej związane z posługiwaniem się nazwą Java w nazwach specyfikacji. Proponowane rozwiązania obejmowały:

1. pozostawienie specyfikacji, w których nie są przewidywane zmiany w takiej postaci w jakiej były, a zmianie miałyby ulec jedynie specyfikacje, które będą dalej rozwijane,
2. zmiana nazw wszystkich specyfikacji, aby pozbyć się z nich słowa Java.

Ostatecznie zdecydowano się na wdrożenie drugiego rozwiązania i z tego powodu zmieniły się nazwy wszystkich specyfikacji, np.:

• Java Server Pages zmieniło się na Jakarta Server Pages,
• Java Persistence API zmieniło się w Jakarta Persistence,
• itp.

Oprócz nazw zmieniły się także przestrzenie nazw i pakietów. Z tego powodu Jakarta EE 9 nie jest kompatybilna z poprzednimi wersjami Javy EE / Jakarty EE 8. Dodatkowo wymaga ona do działania co najmniej Javy 8.

W praktyce wygląda to tak, że dawniej przykładowa klasa serwletu wyglądała np. tak:

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter writer = response.getWriter();
    }
}

W Jakarcie EE 9 wygląda to teraz tak (zwróć uwagę na importy):

import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        PrintWriter writer = response.getWriter();
    }
}

Powiązanie ze Springiem

Często pojawiającym się pytaniem w kontekście Javy EE i Jakarty EE jest: czy uczyć się Javy/Jakarty EE, czy Springa? Spring posiada dziś dominującą pozycję na rynku i jest zdecydowanie najpopularniejszą platformą do tworzenia aplikacji w Javie. Nie jest to jednak rozwiązanie alternatywne dla Jakarty EE, a raczej jego rozszerzenie. Przykładowo tworząc aplikację w Spring MVC pod spodem wykorzystywane są serwlety, do komunikacji z bazami danych wykorzystywany jest Spring Data, który rozwija możliwości JPA, a do walidacji wykorzystywana jest specyfikacja Bean Validation. W skład Springa wchodzi także wiele innych projektów, które nie mają związku z Jakartą EE, jednak w większości przypadków nie da się uniknąć korzystania choćby z części specyfikacji platformy Jakarta EE.

Zależności projektu

W celu utworzenia projektu zgodnego z Jakartą EE 9 najlepiej skorzystać z systemu budowania. Możesz wykorzystać Mavena lub Gradle. Korzystając z serwera aplikacji takiego jak Glassfish, który dostarcza implementację wszystkich specyfikacji możesz do projektu dodać tylko jedną zależność:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>9.0.0</version>
    <scope>provided</scope>
</dependency>

Możesz jednak wskazać także tylko pojedyncze specyfikacje, np. w przypadku serwletów, które są wystarczające do stworzenia prostych aplikacji webowych, do projektu wystarczy dodać:

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>5.0.0</version>
    <scope>provided</scope>
</dependency>