
原本计划在 2024 年 7 月正式发布的Jakarta EE 11,最终只在 2024 年 12 月和 2025 年 4 月分别交付了Core Profile和Web Profile。现在,在Jakarta EE 10发布 34 个月后,Eclipse 基金会正式发布了包括 Jakarta EE 11平台在内的 Jakarta EE 11。虽然这可能被说成是“又一次严重推迟”,但这是有实际原因的。
到 2024 年 5 月,所有面向 Jakarta EE 11 的 16 个更新规范通过了各自的审查和 TCK 后,Jakarta EE工作组决定重点关注一项早该开展的工作,对过时的技术兼容性套件(TCK)进行现代化改进和重构。这项工作主要涉及构建工具和测试套件的迁移,即:Ant 迁移到 Maven;TestHarness 迁移到 Arquillian。为此,他们使用了OpenRewrite。这是一个开源的源代码自动重构生态系统。这项投资改善了兼容性测试,降低了在 Jakarta EE 生态系统增长和演变的过程中增加更多测试的门槛。
Jakarta EE 11 平台定义了一个标准平台,用于托管所有 Jakarta EE 应用程序。它是为需要全套 Jakarta EE 规范来开发企业级应用程序的开发人员而设计的。该平台包含的规范如下图所示。

Jakarta EE 11 Web Profile 定义了 Jakarta EE 平台的一个子集,其中包含专门用于开发 Web 应用程序的 Web 技术。Web Profile 中包含的规范如下图所示。

Web Profile 于 2025 年 4 月发布,Eclipse GlassFish 8.0.0-M11是正式批准的兼容实现。
Jakarta EE 11 Core Profile 在 Jakarta EE 10 中引入,定义了 Jakarta EE 平台规范的一个子集,针对适合微服务和提前编译的空间占用比较小的运行时。它致力于为云原生运行时提供一个最小的基础,包括支持构建时应用程序的运行时。Core Profile 中包含的规范如下图所示。

Core Profile 仅包含七个规范,规模相对较小,因此在 2024 年 12 月第一个发布。WildFly预览版34.0.0 和Open Liberty 2024.0.0.11-beta 在 2024 年 10 月下旬提交了兼容性认证请求,以认证成为 Core Profile 的兼容实现。
如上图所示,Jakarta EE 生态系统中有 16 个规范已更新为 Jakarta EE 11。请注意,有两个规范的名称发生了变化,即:Jakarta Validation(以前称为 Jakarta Bean Validation)和 Jakarta Pages(以前称为 Jakarta Server Pages)。在 Jakarta EE 10 发布时,Jakarta Server Faces 已更名为 Jakarta Faces。
Jakarta Data 1.0是 Jakarta EE 11 平台和 Web Profile 中新增的一个规范,提供了一个 API,可以简化数据库技术的访问。它可以将持久性从模型中分离出来,这依赖于多项功能,如在Repository
接口中组合自定义查询方法的能力,而框架将实现这个接口。当前,Jakarta Data 的实现包括Hibernate ORM 6.6.0、Eclipse JNoSQL 1.1.4 和Open Liberty 24.0.0.6。
Jakarta EE 11 中其他值得注意的变化包括:
在Jakarta表达式语言、Jakarta Persistence和Jakarta Validation规范中支持 Java 记录。
使用 JDK 21 时,支持Jakarta Concurrency规范中的虚拟线程。
CDI Lite,一个新的规范文档,补充了Jakarta Contexts和依赖注入规范,分离出旨在解决循环依赖问题的与集成相关的规范文本。
从Jakarta SOAP with Attachments、Jakarta XML Web Services和Jakarta XML Binding规范中移除了最后在 Jakarta EE 10 中更新过的可选特性。
移除对在 JDK 17 中弃用并在 JDK 24 中永久禁用的类 Java SecurityManager的引用。
移除遗留的@MangedBean注解。
在回顾 Jakarta EE 工作组的努力时,微软 Java 首席架构师兼 Jakarta EE 11 发布协调员Ed Burns告诉 InfoQ:
企业软件开发领域正处于一个关键时刻。生成式 AI 的出现使人们有了产品开发速度大幅提升的期望。对于我们在 Jakarta EE 中习惯的基于标准的缓慢开发节奏,这提出了新的挑战。
尽管 Jakarta EE 11 的发布比我预期的要晚得多,但它确实表明,我们正在以两种重要的方式加快自己前进的步伐。
1、证明全新的技术可以添加到标准中并带来价值。
2、完成 Jakarta EE 历史上最大的技术债务偿还。
对于第 1 点,Jakarta Data 是标准的最佳体现:从其他地方吸取经过验证的经验教训,并将其带给尽可能广泛的受众,而不是将价值局限在任何一个单一的供应商那里。
对于第 2 点,Jakarta EE TCK 已经基于当前的测试技术重新构建,消除了对一项在 JUnit 广泛使用之前就未被维护过的测试技术的严重依赖。
Jakarta EE 11 带来了许多其他价值,但这些更多的是渐进式的,坦率地说,对于一项代表稳定性和 IT 投资保护的技术来说,这是非常合适的。
2023 年 3 月,Payara 首席执行官Steve Millidge描述了 Jakarta EE 11 如何成为“Jakarta 的第一次大飞跃”,他写道:
从最初的 lift and shift [Jakarta EE 8]到 Jakarta EE 9 中命名空间的变更,再到 Jakarta EE 10 中完成的简化工作,人们已经投入了大量的努力,使 Jakarta EE 成为了开源开发者进行应用程序开发的坚实基础。
有了这个基础,从现在开始,Jakarta EE 有机会超越 Java EE 时代了。随着 Java 21 的临近,现在有机会确保 Jakarta EE 始终能够利用最新 Java 版本中最新、最强大的功能,构建新规范,并进一步统一和简化平台。
Jakarta EE 11 带来了一个新规范和一个全新的 TCK,Millidge 两年前的想法似乎已经开花结果。
要了解关于 Jakarta EE 11 新特性的更多细节,可以查看Eclipse基金会的博文。该文由 Eclipse 基金会 Jakarta EE 项目经理Tanja Obradovic撰写。
编辑注
Michael Redlich 是 Jakarta Data 规范的提交者。Jakarta EE 11 相关图片由 Eclipse 基金会提供。
声明:本文为 InfoQ 翻译,未经许可禁止转载。
原文链接:https://www.infoq.com/news/2025/07/jakarta-ee-11-updates/
评论