JEP 320: Remove the Java EE and CORBA Modules

Аннотация

Удалить модули Java EE и CORBA из платформы Java SE и из JDK. Эти модули получили статус Deprecated (устаревший) в Java SE 9 с заявленным намерением удалить их в одном из будущих выпусков.

Мотивация

Java SE 6 включала полный стек веб-сервисов для удобства Java-разработчиков. Стек состоял из четырёх технологий, которые изначально разрабатывались для платформы Java EE: JAX-WS (Java API for XML-Based Web Services), JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework) и Common Annotations. На момент включения версии в Java SE совпадали с версиями в Java EE, за исключением того, что в Java SE не вошёл пакет Common Annotations, касающийся модели безопасности Java EE. Однако со временем версии в Java EE развивались, что создавало трудности для версий в Java SE:

• Технологии получали возможности, не относящиеся к Java SE. Например, в Java EE 6 в Common Annotations добавился пакет, касающийся источников данных в контейнере Java EE. Из-за этого приходилось периодически делать снимок версий Java EE и выделять из них подмножество, что отнимало время у инженеров JDK и сбивало с толку разработчиков.

• Технологии сопровождались вышестоящими (upstream) проектами на java.net, а позднее на GitHub. Это затрудняло сопровождение, поскольку версии Java SE в репозиториях OpenJDK приходилось синхронизировать с версиями Java EE в вышестоящих репозиториях.

• Разработчики могли получить автономные версии технологий из вышестоящих проектов и развернуть их с помощью механизма Endorsed Standards Override Mechanism. Этот давно существующий механизм позволял автономным версиям безопасно переопределять версии Java SE. К сожалению, на практике он широко не использовался, и вместо него разработчики применяли нестандартные способы развёртывания автономных версий: например, добавляли их в начало bootstrap class path JDK или просто помещали их в class path в надежде, что возникающие в результате разделённые пакеты (split packages) не вызовут проблем.

Поскольку автономные версии технологий Java EE легко получить со сторонних сайтов, например из Maven Central, платформе Java SE и JDK незачем их включать.

Ещё один случай, когда Java SE включала технологии для удобства разработчиков, относится к 1998 году. Под выдающимся руководством Ken Cavanaugh Java SE приняла CORBA, включив в поставку OMG CORBA API, реализацию ORB, реализацию CosNaming, компилятор idlj, а также поддержку IDL и IIOP в компиляторе rmic. Однако со временем поддержка CORBA стала проблемной:

• Поскольку CORBA — «Endorsed Standard» (одобренный стандарт), развивающийся вне Java Community Process, к сопровождению CORBA в JDK и к возможности безопасно переопределить реализацию CORBA в JDK применимы те же замечания, что и для веб-сервисов. Реалистичной перспективы синхронизировать ORB в JDK с ORB в серверах приложений Java EE нет.

• Значимого интереса к разработке современных приложений с CORBA на Java нет. Кроме того, в Java EE 8 CORBA, RMI-IIOP и JavaIDL отнесены к «Proposed Optional», что означает, что обязательная поддержка этих технологий в будущем может быть отменена.

Поскольку затраты на сопровождение поддержки CORBA перевешивают выгоды, оснований включать её в платформу Java SE или в JDK нет.

Наконец, Java SE включает подмножество JTA (Java Transaction API) начиная с Java SE 1.3 и подмножество J2EE Activity Service for Extended Transactions (J2EE Activity Service) начиная с Java SE 5.0.

JTA состоит из двух пакетов, которые играют разные роли и требуют разного подхода:

• Пакет javax.transaction.xa поддерживает XA-транзакции в JDBC. Этот «XA-пакет» в Java SE 9 находится вместе с JDBC в модуле java.sql. Поскольку модуль java.sql не является обновляемым (upgradeable), автономная версия JTA не может переопределить версию XA-пакета из Java SE, но для приложений это, как правило, приемлемо: XA-пакет стабилен уже много лет, а версия в Java SE идентична версии в Java EE. Для удобства сопровождения XA-пакет в Java SE в будущем может быть перенесён в другой необновляемый модуль, но с точки зрения архитектуры он надолго останется в Java SE рядом с JDBC, и в дальнейшем этот JEP его не касается.

• Пакет javax.transaction определяет общий API управления транзакциями. Версия этого пакета из Java EE всегда выходила за рамки Java SE и развивалась в направлениях, не относящихся к Java SE. Например, в Java EE 7 в JTA добавились типы, касающиеся CDI. Подмножество javax.transaction, определённое в Java SE, поддерживает взаимодействие со службами транзакций CORBA. Этот «пакет взаимодействия с CORBA» в Java SE 9 находится в отдельном модуле java.transaction. Однако версия из Java SE обычно не устраивает приложения, использующие службы транзакций CORBA, поэтому они, как правило, переопределяют её версией из Java EE.

J2EE Activity Service определяет универсальный API промежуточного ПО. Он не обновлялся с 2006 года и не входит в платформу Java EE. Для этого JEP он важен лишь потому, что Java SE включает подмножество одного из его пакетов, javax.activity, для взаимодействия со службами транзакций CORBA. Этот «пакет activity» в Java SE 9 находится в модуле java.corba.

Без поддержки CORBA в платформе Java SE или в JDK нет оснований включать пакет взаимодействия с CORBA из JTA или пакет activity из J2EE Activity Service.

Описание

В Java SE 9 модули Java SE, содержавшие технологии Java EE и CORBA, были помечены как Deprecated for Removal (устаревший, будет удалён), что означает намерение удалить их в одном из будущих выпусков:

• java.xml.ws (JAX-WS, а также связанные технологии SAAJ и Web Services Metadata)
• java.xml.bind (JAXB)
• java.activation (JAF)
• java.xml.ws.annotation (Common Annotations)
• java.corba (CORBA)
• java.transaction (JTA)

Связанные модули в Java SE 9 также были помечены как Deprecated for Removal:

• java.se.ee (модуль-агрегатор для шести модулей выше)
• jdk.xml.ws (инструменты для JAX-WS)
• jdk.xml.bind (инструменты для JAXB)

Поскольку пометка модулей как Deprecated for Removal лишь вызывает предупреждения при компиляции, в JDK 9 был сделан более решительный шаг, чтобы подготовить разработчиков к фактическому удалению этих модулей в одном из будущих выпусков: при компиляции или запуске кода из class path модули в образе среды выполнения JDK не разрешались. Благодаря этому разработчики на JDK 9 могли развёртывать автономные версии технологий Java EE и CORBA в class path, как и на JDK 8. Кроме того, разработчики на JDK 9 могли указать --add-modules в командной строке, чтобы модули в образе среды выполнения JDK разрешались.

В Java SE 11 перечисленные выше девять модулей будут удалены:

• Их исходный код будет удалён из репозитория OpenJDK.
• Их классов не будет в образе среды выполнения JDK.
• Их инструменты больше не будут доступны:
  • wsgen и wsimport (из jdk.xml.ws)
  • schemagen и xjc (из jdk.xml.bind)
  • idlj, orbd, servertool и tnamesrv (из java.corba)
• Провайдер JNDI CosNaming (из java.corba) больше не будет доступен.
• Никакой флаг командной строки не сможет их включить, как это делает --add-modules в JDK 9.

Компилятор rmic будет обновлён: из него будут удалены параметры -idl и -iiop. Как следствие, rmic больше не сможет генерировать заглушки (stubs) и классы tie для IDL или IIOP.

Документация JDK и man-страницы будут обновлены: из них будут удалены все упоминания этих модулей и инструментов, а также будут отражены изменения в rmic.

Тестирование

Все тесты JDK, JCK и SQE, проверяющие API Java EE или CORBA, будут удалены.

Риски и допущения

Модули Java EE

Риск удаления модулей Java EE состоит в том, что приложения не будут компилироваться или запускаться, если они рассчитывают на встроенную («out of the box») поддержку API и инструментов Java EE в JDK. Такие приложения столкнутся с бинарной несовместимостью и несовместимостью исходного кода при переходе с JDK 6, 7 или 8 на JDK 9 или более поздний выпуск. В целом такие приложения делятся на две категории:

1. Автономные программы, работающие с веб-сервисами и XML вне сервера приложений Java EE.

2. Приложения, не связанные с веб-сервисами или XML, но использующие отдельные классы API Java EE для функциональности общего назначения. Например, некоторые приложения используют JAXB не для привязки XML, а ради поддержки Base64, которую предоставляет класс javax.xml.bind.DatatypeConverter. (Исторически этот класс был лучшим выбором, чем класс sun.misc.Base64{Encoder,Decoder}, хотя ещё лучше класс java.util.Base64, появившийся в Java SE 8.) Другой пример: некоторые приложения используют аннотацию @Generated, тип которой, javax.annotation.Generated, в JDK 9 находится вместе с JAX-WS. (Вместо этого приложения могут использовать тип javax.annotation.processing.Generated, появившийся в Java SE 9.).

Ещё один риск удаления модулей Java EE: приложения, которые уже перешли с JDK 6, 7 или 8 на JDK 9, не запустятся, если используют флаг командной строки --add-modules java.se.ee, --add-modules java.xml.bind и т. д.

Это предложение исходит из того, что разработчики, которые хотят компилировать или запускать приложения на последнем JDK, смогут найти и развернуть альтернативные версии технологий Java EE. Хорошей отправной точкой служат эталонные реализации (Reference Implementations, RI) JAX-WS и JAXB, поскольку они полностью заменяют модули java.xml.ws и java.xml.bind из JDK 9. RI доступны как артефакты Maven (учтите, что их нужно развёртывать в class path):

• com.sun.xml.ws : jaxws-ri (JAX-WS, а также SAAJ и Web Services Metadata)
• com.sun.xml.bind : jaxb-ri (JAXB)

Инструменты для JAX-WS и JAXB также доступны как артефакты Maven:

• wsgen и wsimport: com.sun.xml.ws : jaxws-tools, а также скрипты инструментов
• schemagen и xjc: com.sun.xml.bind : jaxb-jxc и com.sun.xml.bind : jaxb-xjc, а также скрипты инструментов

Есть также артефакты Maven, содержащие только API технологий Java EE:

• javax.xml.ws : jaxws-api (JAX-WS, а также javax.xml.soap : javax.xml.soap-api для SAAJ и javax.xml : webservices-api для Web Services Metadata)
• javax.xml.bind : jaxb-api (JAXB)
• javax.activation : javax.activation-api (JAF)
• javax.annotation : javax.annotation-api (Common Annotations)

После реализации этого JEP эти JAR-файлы API можно будет развёртывать в class path, как и на JDK 8 и 9. Их также можно будет развёртывать в module path, чтобы модульные приложения могли зависеть от них с помощью директивы requires:

• JAR-файлы API для JAX-WS, JAXB и SAAJ — это явные модули с именами java.xml.ws, java.xml.bind и java.xml.soap.

• JAR-файл API для Web Services Metadata — это автоматический модуль с именем webservices.api. (Это имя получено из имени JAR-файла, поскольку в манифест JAR не был добавлен атрибут Automatic-Module-Name.)

• JAR-файлы API для JAF и Common Annotations — это автоматические модули с именами java.activation и java.annotation. (Эти имена заданы атрибутом Automatic-Module-Name в манифестах JAR.)

В JDK 9 все модули, упомянутые в разделе «Описание» (кроме агрегатора java.se.ee), являются обновляемыми. Поэтому разработчики, которые в JDK 9 используют --add-modules java.xml.bind и т. п., могут выбрать: либо полагаться на модули Java EE в образе среды выполнения JDK, либо заменить их, разместив JAR-файлы API на upgrade module path. Обратите внимание, что речь идёт именно об upgrade module path, а не о пути модулей: в JDK 9 размещение JAR-файлов API на пути модулей ни на что не влияет, даже если используется --add-modules java.xml.bind и т. п., поскольку модули Java EE в образе среды выполнения JDK имеют приоритет над одноимёнными модулями на пути модулей. После реализации этого JEP модулей Java EE в образе среды выполнения JDK не будет, поэтому разработчики смогут размещать JAR-файлы API на пути модулей.

Модули CORBA и JTA

Риски удаления модуля java.corba:

1. Реализации CORBA не будут компилироваться или запускаться, если они включают только часть «одобренных» (endorsed) API CORBA и рассчитывают, что остальное предоставит JDK.

2. Приложения и реализации CORBA, использующие RMI-IIOP, не будут компилироваться или запускаться. Пакеты RMI-IIOP (javax.rmi и javax.rmi.CORBA) находятся в модуле java.corba и привязаны к содержащейся в нём реализации CORBA, поэтому после удаления java.corba поддержки RMI-IIOP в Java SE не будет.

3. Приложения и реализации CORBA, использующие пакет javax.activity, не будут компилироваться или запускаться. Этот пакет находится в модуле java.corba и привязан к содержащейся в нём реализации CORBA, поэтому после удаления java.corba его поддержки в Java SE не будет.

Отдельной версии CORBA не будет, если только сопровождение API CORBA, реализации ORB, провайдера CosNaming и т. д. не возьмут на себя третьи стороны. Сопровождение третьими сторонами возможно, поскольку платформа Java SE допускает независимые реализации CORBA. API для RMI-IIOP, напротив, определено и реализовано только в рамках Java SE. Отдельной версии RMI-IIOP не будет, если только для её сопровождения не будет начат отдельный JSR или руководство этим API не возьмёт на себя Eclipse Foundation. Передача руководства Java EE от JCP к Eclipse Foundation включает реализацию CORBA и RMI-IIOP из GlassFish. Наконец, отдельной версии J2EE Activity Service нет.

Отдельная версия JTA доступна в виде Maven-артефакта javax.transaction : javax.transaction-api. На ноябрь 2017 года этот JAR-файл соответствует JTA 1.2, которая включает и пакет XA, и пакет взаимодействия с CORBA. В начале 2018 года будет определена JTA 1.3, в которую войдёт только пакет взаимодействия с CORBA; JAR-файл будет обновлён соответствующим образом. JAR-файлы для JTA 1.2 и JTA 1.3 можно размещать следующим образом:

• JAR-файл для JTA 1.2 можно разместить в пути классов. (Пакет XA из JAR-файла игнорируется, вместо него используется пакет XA из модуля java.sql. Пакет взаимодействия с CORBA из JAR-файла используется вместо пакета из модуля java.transaction, который в JDK 9 по умолчанию не разрешается. Обратите внимание, что если в JDK 9 используется --add-modules java.se.ee или --add-modules java.transaction, то пакет взаимодействия с CORBA из JAR-файла будет игнорироваться, а вместо него будет использоваться пакет из модуля java.transaction.)

• JAR-файл для JTA 1.2 нельзя размещать на пути модулей. (Он рассматривался бы как автоматический модуль, содержащий пакет XA, но этот пакет конфликтовал бы с пакетом XA из модуля java.sql.)

• JAR-файл для JTA 1.3 можно разместить в пути классов. (Пакет взаимодействия с CORBA из JAR-файла используется вместо пакета из модуля java.transaction, который в JDK 9 по умолчанию не разрешается.)

• JAR-файл для JTA 1.3 можно разместить на пути модулей и использовать как автоматический модуль с именем java.transaction.