Uncategorized

Джакарта EE 9.1 и дорога в Джакарту EE 10

Джакарта EE 9.1

Через пять месяцев после выпуска Jakarta EE 9 рабочая группа Jakarta EE объявила о выпуске спецификаций платформы и веб-профиля для Jakarta EE 9.1 и связанных TCK. С момента его дебюта в 2018 году были выпущены две основные версии – Jakarta EE 8 в 2019 году и Jakarta EE 9 в 2020 году. Это первый инкрементный точечный выпуск, в котором разработчики теперь могут: разрабатывать и развертывать приложения Jakarta EE 9.1 на JDK 11 и JDK 8; воспользоваться преимуществами новых функций Java SE 11 и новых технологий, добавленных после Java SE 8; без изменений перенести существующие приложения Jakarta EE 9 на Java SE 11; и перенести существующие приложения Java EE и Jakarta EE 8 в Jakarta EE 9.1, используя тот же простой процесс, что и для миграции в Jakarta EE 9.

В настоящее время существует пять совместимых реализаций Jakarta EE 9.1, в том числе IBM и Tomitribe, недавно объявившие, что Open Liberty и TomEE, соответственно, прошли TCK. Все они сертифицированы по платформе и веб-профилю, за исключением случаев, когда указано:

Tomitribe и Apache Software Foundation прошли долгий путь, чтобы сертифицировать TomEE как реализацию, совместимую с Jakarta EE 9.1. Дэвид Блевинс, генеральный директор Tomitribe, вспоминая этот путь и путь к Jakarta EE 10, сказал InfoQ:

Выпуск Jakarta EE 9.1 является не чем иным, как историческим для Apache TomEE и сообщества Apache. Все проекты Apache, включая TomEE, Tomcat, CXF, ActiveMQ, MyFaces и другие, потеряли доступ к Java EE TCK в 2013 году, когда истек срок 10-летней лицензии Apache на Java EE. Этот доступ был восстановлен с помощью первого выпуска Jakarta EE в сентябре 2019 года, и за последние 20 месяцев мы в сообществе TomEE смогли закрыть пробел в трех основных версиях EE (7, 8 и 9) и достичь веб-профиля Jakarta EE 9.1. аттестация в день выпуска.

Покинув JCP в 2010 году, Apache присоединился к Рабочей группе Jakarta EE в качестве приглашенного члена. Значение этих двух событий невозможно переоценить. Мы с нетерпением ждем основного профиля Jakarta EE 10 и отказа от накопившихся за почти 10 лет идей в следующих выпусках Jakarta EE. Это важный момент.

Дорога в Джакарту EE 10

Выпуск версии GA запланирован на первый квартал 2022 года, разработка Jakarta EE 10 уже ведется, и многие спецификации в настоящее время обновляются. Также будет сосредоточено внимание на улучшенном согласовании с Jakarta Contexts and Dependency Injection (CDI), чтобы дополнить то, что эта спецификация уже поддерживает на платформе Jakarta EE, например, @Transactional аннотации в Jakarta Transactions, устаревание управляемого bean-компонента в Jakarta Server Faces и использование CDI в Jakarta Security.

Спецификации Jakarta EE, которые выиграют от CDI, включают: вводимые артефакты в Jakarta Batch; осуждать @Context аннотация в пользу внедрения CDI в Jakarta RESTful Web Services; и улучшено распространение контекста CDI в Jakarta Concurrency.

Несмотря на наличие установленной спецификации Jakarta Enterprise Beans с версиями, поддерживающими Jakarta EE 8 и Jakarta EE 9, дальнейшее развитие этой спецификации в настоящее время маловероятно. Однако Арьян Теймс, частный консультант по Java, обсудил важность продолжения поддержки этой спецификации, написав:

В планах Jakarta EE 10 – внедрение версий на основе CDI почти всех функций Enterprise Bean. Эти функции, наряду с такими функциями Enterprise Beans, как @Transactional, у которых уже есть альтернативы, означают, что в новом коде не нужно будет использовать много технологий Jakarta Enterprise Beans, если таковые имеются.

Тем не менее, есть еще один важный вариант использования, который следует учитывать: существующий код, который все еще использует множество корпоративных компонентов, таких как @Stateless аннотация. Старые технологии, такие как Eclipse GlassFish, скорее всего, сохранят свои почтенные реализации Enterprise Beans в течение долгого времени, и в ближайшее время нет планов отменять или сокращать спецификацию.

Рабочая группа Jakarta EE также определила цель предсказать, как спецификации Jakarta EE будут согласованы с конкретной версией Java SE. Обсуждения еженедельных звонков платформы для определения того, какая версия Java SE должна потребоваться для Jakarta EE 10, позволили получить ряд вариантов, которые были сужены до трех. Сообщество Java имело возможность проголосовать за понравившийся вариант:

  • Вариант 1: источник = Java SE 11, bin = Java SE 11, TCK = Java SE 11+
    • Java SE 11 как уровень исходного кода / языка и двоичный уровень для всех API JAR. Совместимые реализации могут бесплатно передавать TCK с использованием любой версии Java SE 11 или выше.
  • Вариант 2: источник = Java SE 11, bin = Java SE 17, TCK = Java SE 17+
    • Java SE 11 как уровень исходного кода / языка и Java SE 17 как двоичный уровень для всех API JAR. Совместимые реализации могут бесплатно передавать TCK с использованием любой версии Java SE 17 или выше.
  • Вариант 3: источник = Java SE 17, bin = Java SE 17, TCK = Java SE 17+
    • Java SE 17 как уровень исходного кода / языка и двоичный уровень для всех API JAR. Совместимые реализации могут бесплатно передавать TCK с использованием любой версии Java SE 17 или выше.

Окончательное голосование показало, что вариант 1 был предпочтительным вариантом для Jakarta EE 10.

Более подробную информацию о том, что разработчики могут ожидать от Jakarta EE 10, можно найти в этом сообщении в блоге.

Послы Jakarta EE, независимая группа разработчиков Java на низовом уровне, взявшая на себя обязательство продвигать Jakarta EE вперед посредством активного участия и поддержки сообщества, предоставили это руководство по вкладу разработчикам, заинтересованным в участии в Jakarta EE 10.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button