Jakarta EE 对开发人员需求的响应效果如何？

交叉发布在 Ed Burns 博客上。

执行摘要

Jakarta 指导委员会特许了 Jakarta 平台项目，其目标是在 EE 11 的开发中纳入开发人员的反馈。这篇博文回顾了该平台项目的性能，并以 4 分制的方式授予 GPA 3.43 的成绩目标。

介绍

我很荣幸也很荣幸能够帮助交付 Jakarta EE 的下一个版本。几十年来，我在 J2EE/Java EE/Jakarta EE 中担任过许多角色：实施者、规范负责人、倡导者、作者、测试人员等等。然而，我目前的角色对我来说是一个新的发布协调员。

在此职位上，我（与 Arjan Tijms 一起）共同领导 Jakarta 平台项目，该项目负责交付完成的 Jakarta EE 规范（和组件规范）、相应的 TCK，并至少批准兼容的实现所有规格。重要的是，不需要有一个单一的整体实现同时满足所有组件 TCK，但必须有一个通过平台 TCK 的单一整体实现。

本着二十多年前我有幸开始的透明精神，这篇博文探讨了 Jakarta 平台项目在 EE 11 期间在实现指导委员会为平台项目设定的目标之一方面的表现：纳入开发者反馈。

承诺不足和交付过多

制度记忆是人类群体从错误中学习并避免重蹈覆辙的方式。根据这个定义，我希望我们都能同意机构记忆很重要并且值得保存。因为软件是可执行的知识，所以长期运行的开源软件项目是一种特殊的机构记忆。一个由长期运行的开源项目组成的长期运行的生态系统的项目几乎是特殊的顶峰。考虑到所有这些特殊性，纳入开发者反馈意味着什么？

当犯错误的可能成本包含在单个项目中时，显示对开发人员反馈的响应要容易得多。鉴于可能的高成本，Jakarta EE 11 平台项目故意保持低调，以实现纳入开发人员反馈的目标。这是我们对“承诺不足、交付过多”这一久经考验的策略的实施。

在 Jakarta EE 11 发布之前，我们对 Jakarta EE 11 的要求进行了公开社区讨论，并将其记录在本 Jakarta EE 11 讨论文档中。让我们回顾一下我们收到的社区意见（主要是开发人员驱动的），看看我们在 EE11 中的表现如何。

承诺不足

• 雅加达数据

• 雅加达 NoSQL

• 采用 Java SE 11、17、21 新功能和重大更改

• 虚拟线程

• TCK 重构

• 以 CDI 为中心

  • CDI 取代托管 Bean
  • CDI 取代 EJB

• 解决冗余 HTTP 堆栈：Servlet 和 REST

• MicroProfile 和 Jakarta 对齐

• CORS 支持

• 雅加达配置

• 让从一个供应商迁移到另一个供应商变得更容易

混合发货

我将把交付分为四类：超额交付、已交付、部分交付、未交付。

超额交付

• Jakarta Persistence - 编程配置而不是 persistence.xml 以及更多 Gavin King 博客文章
• Jakarta Security - 动态选择身份验证机制 security-311

发表

• 雅加达数据

  • 是的，这个新规范已出现在平台中。

• 采用 Java SE 11、17、21 新功能和重大更改。

  • 是的，有许多规范利用了 11 - 21 的新语言功能。

• TCK 重构（我们将交付此内容。我们正在为其保留发布版本）。

  • Jakarta EE 平台 TCK 是一个重要的软件组件，可实现数十年规模的 IT 投资稳定性价值主张。由于缺乏维护投资，TCK 的软件一直在积累技术债务。在 Jakarta EE 11 中，我们使 TCK 与最先进的测试工具保持同步。随着 Jakarta EE 平台的发展，这项投资将实现更好的兼容性测试，并降低添加更多测试的障碍。

• API 灵活性，即不再需要 Umbrella JAR。

  • 不再有类似“我必须等待 Jakarta EE xx”才能拥有此功能的问题吗？
  • Jakarta EE Platform API 现在只是默认 API 的集合。
  • 个别规格可以由用户根据自己的意愿排除或升级，
  • 也可以添加新规格。
  • 这使得 Jakarta EE 平台像 Spring Boot 一样灵活，但应用程序中没有实现包袱，两全其美！

有点交付

• 虚拟线程

  • 并发规范严格指定了注释属性，要求实现利用虚拟线程（如果虚拟线程在运行时可用）。如果您在 Java 21 或更高版本上运行，则在使用注释属性时会获得虚拟线程。如果你在 17 号跑步，你就不会。

• 以 CDI 为中心

  • CDI 取代托管 Bean。

    • 我们做到了
      • 删除@ManagedBean注释。
      • 将 CDI 的“集成”部分从 CDI 规范移至平台规范。
      • Jakarta Concurrency 在 @Asynchronous 注释中添加了调度，以替换 EJB 并发上的 @Scheduled 注释 - 271
      • 将并发资源注入 CDI bean，而不是在 EJB 并发中使用 @Resource-348。
      • 删除了 Jakarta REST 中的托管 Bean 支持。
      • 持久化中持久化单元的限定符 - 允许以 CDI 惯用方式注入持久化上下文。

• Java 新功能

  • 在 Jakarta Persistence 中记录为可嵌入项和 ID。
  • 用表达语言记录。
  • Validation（以前的 Bean Validation）validation-275 中的记录。
  • 并发中的 Flow API concurreny-368。

• MicroProfile 和 Jakarta 对齐

  • 我们做到了
    • 创建 Jakarta Security MicroProfile 安全桥规范。

没有交付

• 雅加达 NoSQL

  • 这在 EE 11 开发周期开始时没有通过投票。在我看来，原因是非技术性的，因此可以在 EE 12 中解决。

• 解决冗余 HTTP 堆栈：Servlet 和 REST

  • 这是一个非常大的。在我看来，需要一个主要供应商支持这个想法，并投入大量资源来实现它，可能会向竞争对手捐赠工作，这样他们也可以这样做。

• CORS 支持

  • 这个甚至没有出现在我的雷达上。

• 雅加达配置

  • 这个似乎陷入了“MicroProfile 配置足够好”的困境，因此陷入了困境。我认为我们必须说服 MicroProfile 项目允许其从 MicroProfile 转移到 Jakarta EE Core Profile 规范。

• 让从一个供应商迁移到另一个供应商变得更容易

  • 这与每个供应商的商业利益是对立的，所以我认为这一点不会受到太多关注。

概括

让我们定量一下。对于Underpromise列表中的每一项，我都会给我们一个字母等级。 A 表示超额交付或交付，B 表示部分交付，D 表示未交付。

Feedback to incorporate	Grade
Jakarta Data	A
Jakarta NoSQL	D
Adopt Java SE 11, 17, 21 new features and Breaking Changes	A
Virtual Threads	A
TCK Refactoring	A
CDI Centric	A
Resolve redundant HTTP stacks: Servlet and REST	D
MicroProfile and Jakarta Alignment	B
CORS support	D
Jakarta Config	D
Make it easier to migrate from one vendor to another	D

通过这份清单，我们的 GPA 只达到了 2.54。不太好。如果我们从列表中删除我认为不现实的开发人员反馈请求（CORS、冗余 HTTP 堆栈、Jakarta 配置、使从一个供应商迁移到另一个供应商变得更容易），我们会得到更好的分数：3.43。不错，但我们还有成长的空间。

以上是Jakarta EE 对开发人员需求的响应效果如何？的详细内容。更多信息请关注PHP中文网其他相关文章！