Java EE и Jakarta EE: что это, история платформы и из чего она состоит

Java EE (Java Platform, Enterprise Edition) — это набор спецификаций для серверных Java-приложений: веб-запросы, работа с базами данных, транзакции, обмен сообщениями, безопасность. С 2019 года платформа развивается в Eclipse Foundation под именем Jakarta EE, а ее API постепенно переехали из пакетов javax.* в jakarta.*.

Важно сразу развести три вещи. Java SE — сам язык, JVM и стандартная библиотека. Java EE / Jakarta EE — спецификации поверх Java SE. Сервер приложений (GlassFish, WildFly, Open Liberty и другие) — конкретная реализация этих спецификаций. Ниже — история платформы, ее состав, профили, связь со Spring и рабочий пример на Jakarta EE 11.

Мини-словарь: спецификация, API, реализация, профиль

Аналогия-якорь: спецификация похожа на интерфейс в Java. Интерфейс сам ничего не делает, он задает контракт, а работу выполняют классы-реализации. Приложение, написанное по контракту, в идеале переносится между серверами. На практике переносимость ограничена: конфигурация, дескрипторы и расширения конкретного сервера обычно отличаются.

История: от J2EE до Jakarta EE 11

На сентябрь 2026 года актуальная версия — Jakarta EE 11 (полная платформа вышла 26 июня 2025 года). Jakarta EE 12 находится в разработке и еще не выпущена.

В 2017 году Oracle объявила о передаче Java EE в Eclipse Foundation. Код и спецификации передали, а товарный знак «Java» и право менять пакеты javax.* остались у Oracle. Поэтому платформа получила имя Jakarta EE, а новые версии API пришлось выпускать в пространстве jakarta.*.

Граница переименования: в jakarta.* переехали только пакеты enterprise-спецификаций. Пакеты Java SE вроде javax.crypto или javax.swing остались на месте, это часть JDK.

Минимальный пример: сервлет на Jakarta EE 11

Проверено 23.09.2026 в Apache Tomcat 11.0.26 на JDK 25 (Temurin). Tomcat реализует Servlet 6.1 из Jakarta EE 11. Сервлет отвечает на GET-запрос текстом и проверяет входной параметр:

import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        String name = req.getParameter("name");
        if (name == null || !name.matches("[\\p{L} -]{1,40}")) {
            name = "гость";
        }
        resp.setContentType("text/plain; charset=UTF-8");
        resp.getWriter().println("Привет, " + name + "!");
        resp.getWriter().println("Контейнер: " + getServletContext().getServerInfo());
        resp.getWriter().println("Servlet API: "
                + getServletContext().getMajorVersion() + "."
                + getServletContext().getMinorVersion());
    }
}

Компиляция и раскладка в приложение demo (внутри каталога Tomcat):

mkdir -p webapps/demo/WEB-INF/classes
javac -encoding UTF-8 -cp lib/servlet-api.jar -d webapps/demo/WEB-INF/classes HelloServlet.java
bin/catalina.sh start

Запрос /demo/hello?name=Анна (в URL имя передается в percent-кодировке) вернул статус 200 и такой ответ:

Привет, Анна!
Контейнер: Apache Tomcat/11.0.26
Servlet API: 6.1

Запрос с name=<script> не прошел проверку и получил «Привет, гость!», а несуществующий путь /demo/nope — статус 404.

Что здесь делает контейнер, а что код. Аннотация @WebServlet регистрирует класс на адресе /hello без файла web.xml. Контейнер сам создает экземпляр сервлета, разбирает HTTP-запрос и вызывает doGet. Код отвечает только за логику.

Проверка имени по шаблону — это валидация входа, а тип text/plain защищает от интерпретации ответа как HTML. Это разные меры, и для HTML-страниц все равно нужно кодирование вывода. Пример учебный: аутентификации, журналирования и ограничения частоты запросов в нем нет.

Ошибка: старый код с javax на новом сервере

Частая ситуация — взять пример из статьи 2015 года и собрать его на Tomcat 10+ или другом сервере Jakarta EE 9+. Тот же класс, но с импортами javax.servlet:

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

Результат компиляции против servlet-api.jar из Tomcat 11 (начало вывода javac):

HelloServlet.java:1: error: package javax.servlet.annotation does not exist
import javax.servlet.annotation.WebServlet;
                               ^
...
12 errors

Исправление — заменить javax.servlet на jakarta.servlet во всех импортах, а в сборке подключить API нужной версии Jakarta EE. Для больших проектов замену делают инструментами миграции, а не вручную. Сторонние библиотеки тоже должны быть собраны под jakarta.*, иначе ошибка переедет из компиляции в запуск.

Из чего состоит платформа

Спецификации удобно раскладывать по слоям типичного приложения. Список неполный, здесь основные:

Отдельно о том, чего в современной платформе нет. Апплеты давно не запускаются браузерами, их API объявили устаревшим в Java 17 и удалили из JDK 26. Тексты, где апплеты названы частью Java EE, описывают платформу до 2010-х. JDBC — часть Java SE, а не Java EE, хотя серверы приложений дают для нее пулы соединений.

Профили и серверы приложений

Совместимые реализации проходят набор тестов TCK. Известные серверы: Eclipse GlassFish, WildFly (и коммерческий JBoss EAP), Open Liberty, Payara. Какой из них сертифицирован для конкретной версии и профиля, смотрят на официальной странице совместимости Eclipse Foundation на дату выбора.

Tomcat и Jetty — не полные серверы приложений. Это веб-контейнеры: они реализуют Servlet, Pages, Expression Language, WebSocket и часть смежных спецификаций. Для CDI или JPA к ним добавляют библиотеки, либо берут полный сервер.

Jakarta EE и Spring

Spring Framework — не реализация Jakarta EE, а отдельный фреймворк со своим контейнером внедрения зависимостей. При этом он опирается на отдельные спецификации Jakarta: Servlet для веб-слоя, Persistence через Hibernate, Bean Validation.

Поэтому переезд на jakarta.* затронул и Spring: Spring Framework 6 и Spring Boot 3 (2022) перешли на пакеты jakarta.* и требуют Java 17. Приложение на Spring Boot 2 при обновлении до 3.x проходит ту же миграцию импортов, что и классическое Java EE приложение.

Выбор зависит от команды и существующего кода, а не от «новизны». Знание Servlet, JPA, CDI и транзакций полезно в обоих мирах: Spring использует те же понятия.

Выводы

• Java EE и Jakarta EE — одна линия развития: набор спецификаций серверной Java поверх Java SE, с 2019 года под управлением Eclipse Foundation.
• Главное практическое изменение — переезд API из javax.* в jakarta.* в Jakarta EE 9; код со старыми импортами на новых серверах не собирается.
• Спецификация задает контракт, сервер приложений или веб-контейнер его реализует; Tomcat покрывает веб-часть, а не всю платформу.
• Профили (Platform, Web, Core) позволяют брать только нужный набор спецификаций.
• Spring не реализует Jakarta EE, но использует ее отдельные спецификации и прошел ту же миграцию на jakarta.*.

Где применяется / связь с практикой

Jakarta EE и Java EE живут в банковских, страховых и государственных системах, где сервер приложений работает годами, а также в современных сервисах через Spring Boot, который опирается на те же Servlet, JPA и Bean Validation. Для разработчика это значит: понимать контейнер, транзакции и жизненный цикл компонентов приходится почти в любом серверном Java-проекте.

FAQ

Java EE умерла?
Название больше не развивается: последняя Java EE — версия 8. Платформа продолжается как Jakarta EE, а системы на Java EE 8 и Jakarta EE 8 по-прежнему эксплуатируются и мигрируют на новые версии.

Можно ли запустить старый WAR с javax.servlet на Tomcat 11?
Напрямую нет, классы javax.servlet там отсутствуют. Приложение пересобирают под jakarta.* или прогоняют через Apache Tomcat Migration Tool for Jakarta EE (в Tomcat 10+ та же конвертация срабатывает при копировании WAR в каталог webapps-javaee); второй путь подходит как временный.

Что такое MicroProfile и как он связан с Jakarta EE?
Это отдельный набор спецификаций Eclipse Foundation для микросервисов: конфигурация, проверки здоровья, телеметрия, отказоустойчивость. Начиная с MicroProfile 7.0 он объявляет Core Profile Jakarta EE своей зависимостью и дополняет его.