1. Введение
Вы когда-нибудь слышали о Java EE? Как насчет Java 2EE, J2EE, а теперь и Jakarta EE? На самом деле все это разные названия одного и того же: набора корпоративных спецификаций, расширяющих Java SE.
В этой короткой статье мы опишем эволюцию Java EE.
2. История
В первой версии Java корпоративные расширения Java были просто частью ядра JDK .
Затем, как часть Java 2 в 1999 году, эти расширения были отделены от стандартных двоичных файлов, и родилась J2EE , или Java 2 Platform Enterprise Edition . Это название сохранялось до 2006 года.
Для Java 5 в 2006 году J2EE был переименован в Java EE или Java Platform Enterprise Edition. Это имя продержалось до сентября 2017 года, когда произошло что-то важное .
Смотрите, в сентябре 2017 года Oracle решила передать права на Java EE Eclipse Foundation (язык по-прежнему принадлежит Oracle) .
3. В переходный период
На самом деле Eclipse Foundation по закону пришлось переименовать Java EE. Это потому, что у Oracle есть права на бренд «Java».
Таким образом, чтобы выбрать новое имя, сообщество проголосовало и выбрало: Jakarta EE. В некотором смысле это все еще JEE .
* Объявлено новое имя
Тем не менее, это все еще развивающаяся история, и пыль еще не полностью осела.
Например, хотя Oracle открыл исходный код, они не открыли исходный код всей документации. По этому вопросу до сих пор ведется много дискуссий из-за юридических вопросов, которые затрудняют доступ к документации с открытым исходным кодом, связанной, например, с JMS и EJB.
Пока не ясно, сможет ли новая документация Eclipse Foundation ссылаться на оригиналы.
Кроме того, любопытно, что Eclipse Foundation не может создавать новые пакеты Java, используя пространство имен javax , но может создавать новые классы и подклассы в существующих.
Переход также означает новый процесс добавления спецификаций в Jakarta EE. Чтобы лучше понять это, давайте посмотрим, на что был похож этот процесс в Oracle и как он изменился в Eclipse Foundation.
4. Будущее
Исторически сложилось так, что для того, чтобы функция попала в «EE», нам нужны были три вещи: спецификация, эталонная реализация и тесты. Эти три вещи могут быть предоставлены любым членом сообщества, и исполнительный комитет решит, когда они будут готовы добавить в язык.
Чтобы лучше понять прошлый процесс, давайте подробнее рассмотрим, что такое JSR, Glassfish и TCK и как они воплощали в себе новые возможности EE .
Мы также получим представление о том, чего ожидать в будущем.
4.1. JCP и теперь EFSP
В прошлом процесс, посредством которого рождалась новая функция EE, назывался Java Community Process ( JCP ).
Java SE до сих пор использует JCP. Но поскольку EE сменила владельца с Oracle на Eclipse Foundation, у нас есть для этого новый и отдельный процесс. Это процесс спецификации Eclipse Foundation ( EFSP ), который является расширением процесса разработки Eclipse.
Однако есть некоторые важные отличия , в основном касающиеся «Прозрачности, открытости, общего бремени и нейтральности поставщика». Организаторы EFSP, например, представляют себе совместные рабочие группы, нейтральные к поставщикам, процесс сертификации, основанный на самообслуживании, и организацию, которая работает и управляет как меритократия.
4.2. JSR
В JCP первым шагом к добавлению функции в EE было создание JSR или запроса спецификации Java. JSR был немного похож на интерфейс для функции EE. Исполнительный комитет JCP рассмотрел и утвердил завершенный JSR, а затем участники JSR кодировали его и делали доступным для сообщества.
Хорошим примером этого является JSR-339 — или JAX-RS — который был первоначально предложен в 2011 году, одобрен JCP в 2012 году и, наконец, выпущен в 2013 году.
И хотя сообщество всегда могло внести свой вклад во время обсуждения спецификации, время показало, что подход, ориентированный на реализацию, как в случае с JSR 310 , java.time и Joda Time , имеет тенденцию создавать более широко принятые функции и API . .
Таким образом, EFSP отражает этот подход «сначала код» в заявленной цели: «EFSP будет основываться на практических экспериментах и кодировании в первую очередь как на способе доказать, что что-то достойно документирования в спецификации».
4.3. Стеклянная рыба
Затем, как часть JCP, JSR потребовалась эталонная реализация. Это немного похоже на класс , реализующий интерфейс . Эталонная реализация помогает разработчикам совместимых библиотек или другим организациям, которые хотят создать собственную реализацию спецификации.
Для функций Java EE JCP использовала Glassfish для своих эталонных реализаций.
И хотя эта централизация на Glassfish упростила процесс обнаружения для разработчиков, эта централизация также требовала большего контроля и имела тенденцию отдавать предпочтение одному поставщику перед другим.
Следовательно, EFSP не требует эталонной реализации, а требует только совместимой реализации. Проще говоря, это тонкое изменение делает так, что реализация внутри центральной архитектуры, такой как Glassfish, не будет непреднамеренно предпочтительна для фонда.
4.4. ТСК
Наконец, JCP требовал, чтобы функции EE тестировались с помощью комплекта совместимости технологий, или TCK .
TCK представлял собой набор тестов для проверки конкретного EE JSR. Проще говоря, чтобы соответствовать Java EE, сервер приложений должен реализовать все свои JSR и пройти все тесты на назначенном TCK.
Здесь не так много изменений. Oracle открыл исходный код TCK, а также JSR EE. Конечно, все будущие документы и TCK будут с открытым исходным кодом.
5. Вывод
Java EE, безусловно, сильно изменилась за эти годы. Приятно видеть, что он продолжает меняться и улучшаться.
Впереди много испытаний, так что будем надеяться на плавный переход.