Кросспост в блоге Эда Бернса.

Управляющее резюме

Руководящий комитет Джакарты основал проект Jakarta Platform с целью учета отзывов разработчиков при разработке EE 11. В этом сообщении блога рассматривается эффективность проекта Platform и присуждается средний балл 3,43 по 4-балльной шкале за достижение этой цели. цель.

Введение

Для меня большая честь и честь оказаться в состоянии помочь в создании следующей версии Jakarta EE. На протяжении десятилетий я занимал множество должностей в J2EE/Java EE/Jakarta EE: разработчик, руководитель спецификации, защитник, автор, тестировщик и многие другие. Однако моя нынешняя роль — новая для меня, со-координатора выпуска.

В этой роли я являюсь со-руководителем (вместе с Арьяном Таймсом) проекта Jakarta Platform, который отвечает за предоставление готовой спецификации Jakarta EE (и спецификаций компонентов), соответствующего TCK и, по крайней мере, за ратификацию совместимой реализации для все характеристики. Важно отметить, что не обязательно должна быть одна монолитная реализация, которая одновременно удовлетворяет всем TCK компонента, но должна быть одна монолитная реализация, которая передает TCK платформы.

В духе прозрачности, который мне посчастливилось начать более двух десятилетий назад, в этом сообщении блога рассматривается, насколько хорошо проект Джакартской платформы справился во время EE 11 с достижением одной из целей, поставленных перед проектом Платформы Руководящим комитетом: учитывайте отзывы разработчиков.

Недообещать и перевыполнять

Институциональная память — это способ, которым группы людей учатся на ошибках и избегают их повторения. Я надеюсь, что согласно этому определению мы все согласимся с тем, что институциональная память важна и ее стоит сохранять. Поскольку программное обеспечение представляет собой исполняемые знания, очень продолжительный проект программного обеспечения с открытым исходным кодом представляет собой особый вид институциональной памяти. Проект, представляющий собой многолетнюю экосистему давно работающих проектов с открытым исходным кодом, во многом является вершиной чего-то особенного. Учитывая всю эту особенность, что значит учитывать отзывы разработчиков?

Гораздо легче реагировать на отзывы разработчиков, когда возможные издержки совершения ошибки содержатся в рамках одного проекта. В свете возможных высоких затрат проект платформы Jakarta EE 11 был намеренно скромным с нашими целями по учету отзывов разработчиков. Это наша реализация проверенной стратегии «недообещать и перевыполнять».

В преддверии выпуска Jakarta EE 11 мы провели открытое обсуждение в сообществе требований к Jakarta EE 11 и отразили их в этом документе для обсуждения Jakarta EE 11. Давайте рассмотрим отзывы сообщества, которые мы получили, в основном от разработчиков, и посмотрим, как мы справились с EE11.

Недостаточное обещание

• Данные Джакарты

• Джакарта NoSQL

• Принятие новых функций и критических изменений Java SE 11, 17, 21

• Виртуальные темы

• Рефакторинг TCK

• CDI Centric

  • CDI заменяет управляемые компоненты
  • CDI вместо EJB

• Устранение избыточных стеков HTTP: сервлет и REST

• Выравнивание микропрофиля и Джакарты

• Поддержка CORS

• Конфигурация Джакарты

• Упрощение перехода от одного поставщика к другому

Смешанная доставка

Я собираюсь сгруппировать доставку по четырем сегментам: перевыполнено, выполнено, частично выполнено, не выполнено.

Перегружено

• Jakarta Persistence — программная конфигурация вместо persistence.xml и многое другое. Сообщение в блоге Гэвина Кинга
• Jakarta Security — динамически выбирать механизм аутентификации security-311

Доставленный

• Данные Джакарты

  • Да, эта новая спецификация присутствует в платформе.

• Примите новые функции и критические изменения Java SE 11, 17, 21.

  • Да, существует множество спецификаций, в которых используются преимущества новых языковых функций с 11 по 21.

• Рефакторинг TCK (мы выполним это. Мы задержим релиз).

  • Платформа Jakarta EE TCK — это жизненно важный программный компонент, обеспечивающий стабильность инвестиций в ИТ в масштабе десятилетий. Программное обеспечение TCK накапливает технический долг из-за отсутствия инвестиций в обслуживание. В Jakarta EE 11 мы обновляем TCK, используя самые современные инструменты тестирования. Эти инвестиции позволят улучшить тестирование совместимости и снизят барьер для добавления дополнительных тестов по мере развития платформы Jakarta EE.

• Гибкость API, т.е. больше нет зонтичных JAR-файлов.

  • Больше нет вопросов типа «нужно ли мне ждать Jakarta EE xx», чтобы получить эту функцию?
  • API-интерфейсы платформы Jakarta EE теперь представляют собой просто набор API-интерфейсов по умолчанию.
  • Отдельные спецификации могут быть исключены или обновлены пользователем по их желанию,
  • Также можно добавить новые характеристики.
  • Это делает платформу Jakarta EE такой же гибкой, как Spring Boot, но без необходимости реализации в вашем приложении — лучшее из обоих миров!

Несколько доставлено

• Виртуальные темы

  • Спецификация параллелизма строго определяет атрибут аннотации, который требует, чтобы реализации использовали преимущества виртуальных потоков, если они доступны во время выполнения. Если вы используете Java 21 или более позднюю версию, вы получаете виртуальные потоки при использовании атрибута аннотации. Если у вас 17, то нет.

• CDI Centric

  • CDI заменяет управляемые компоненты.

    • Мы сделали
      • удалить аннотацию @ManagedBean.
      • Переместите «интеграционные» части CDI из спецификации CDI в спецификацию платформы.
      • Jakarta Concurrency добавляет планирование в аннотацию @Asynchronous для замены аннотации @Scheduled в EJB concurrency-271
      • Внедрение ресурсов параллелизма в компоненты CDI вместо использования @Resource в EJB concurrency-348.
      • Удалена поддержка управляемых компонентов в Jakarta REST.
      • Квалификаторы для единиц персистентности в персистентности — позволяют вводить контекст персистентности идиоматическим способом CDI.

• Новые функции Java

  • записи как встраиваемые объекты и идентификаторы в Jakarta Persistence.
  • записи на языке выражений.
  • записи в Validation (ранее Bean Validation) validation-275.
  • Flow API в Concurrency concurreny-368.

• Выравнивание микропрофиля и Джакарты

  • Мы сделали
    • Создайте спецификацию моста безопасности Jakarta Security MicroProfile.

Не доставлено

• Джакарта NoSQL

  • Этот вариант не прошел голосование в начале цикла разработки EE 11. На мой взгляд, причины были нетехнические, а значит могут быть решены для EE 12.

• Устранение избыточных стеков HTTP: сервлет и REST

  • Это очень важный момент. По моему мнению, для реализации этой идеи потребуется крупный поставщик, который поддержит эту идею и выделит значительные ресурсы, вероятно, пожертвовав работу конкурентам, чтобы они тоже могли сделать то же самое.

• Поддержка CORS

  • Этот фильм даже не появился на моем радаре.

• Конфигурация Джакарты

  • Похоже, что этот файл застрял в «Конфигурация микропрофиля достаточно хороша» и, таким образом, падает между трещинами. Я думаю, нам придется убедить проект MicroProfile разрешить переход от MicroProfile к спецификации Jakarta EE Core Profile.

• Упрощение перехода от одного поставщика к другому

  • Этот вопрос противоречит бизнес-интересам каждого поставщика, поэтому я не думаю, что он получит много внимания.

Краткое содержание

Давайте перейдем к количественному анализу. По каждому пункту в списке Underpromise я поставлю нам буквенную оценку. A — перегружено или доставлено, B — доставлено частично, D — не доставлено.

С этим списком мы получили средний балл всего 2,54. Не так уж и здорово. Если вычеркнуть из списка запросы на обратную связь от разработчиков, которые, по моему мнению, включить в него нереально (CORS, Резервные стеки HTTP, Jakarta Config, Упрощение перехода от одного поставщика к другому), мы получим более высокую оценку: 3,43. Неплохо, но нам есть куда расти.