在 2025 年 6 月发布Jakarta EE 11之后，Jakarta EE 12 的开发工作一直在顺利进行，这个版本预计将提供改进的集成，并与前一个版本保持一致。
Jakarta EE 12 的四个里程碑版本中的第二个计划在 2026 年第一季度发布。在本文中，我们将讨论新特性和能力，这些将提供一致性和配置，改善 Jakarta EE 开发者体验。此外，我们将突出该平台中发现的一些初始项目。
为什么这个版本对开发者和架构师很重要
当我们谈论 Java 平台本身时，Jakarta EE 12 Milestone 2 重塑了平台，直接影响了 Java 生态系统，而不仅仅是个别规范。
Jakarta EE 12 带来了对数据的新视角，将查询、数据访问、配置和一致性视为平台一级的关注点。因此，Jakarta EE 12 的主题是健壮性和灵活性。
Jakarta EE 是 Quarkus 和 Spring 等 Java 框架的基础。对于开发者来说，这一发展转化为更清晰的 API、更少的跨层重复，以及无论使用哪个框架都感觉熟悉的概念。
对于架构师来说，Jakarta EE（以前称为 Java EE）一直提供稳定性和可移植性，但 Jakarta EE 12 增加了架构的相关性。
该平台现在明确支持多语言持久性、现代 Java 基线和新兴关注点，如基于智能体的 AI 集成，而不会迫使框架陷入非自然的抽象。这种方法创造了更具适应性的架构，此外，多语言持久性，允许架构师为正确的场景选择合适的数据库。
了解 Jakarta EE 12 发布过程
在深入探讨 Jakarta EE 12 Milestone 2 的新内容之前，简要解释开发阶段，包括测试、社区反馈和两个修订里程碑是很重要的。与任何软件开发过程中的典型情况一样，这些规范在最终投票（在这种情况下，由 Jakarta EE 指导委员会对过程进行投票）之前可能会发生变化或延迟。如图 1 所示，这是目前作为 Jakarta EE 12 平台一部分的规范集：
Jakarta EE 平台中的规范
需要注意的是，Jakarta MVC 3.1 和 Jakarta NoSQL 1.1 规范目前正在考虑是否包含在 Jakarta EE 12 平台中。
在 Jakarta EE 11 中，我们看到了 Java 17 作为基准支持 Java 21 的影响。这种包含允许你在 Jakarta 持久性规范中使用 Java 记录作为嵌入式类和 ID，以及在 Jakarta 并发规范中使用虚拟线程。对于 Jakarta EE 12，基线将是支持 Java 25 的 Java 21。在平台层面，这个版本反映了从已弃用的 SecurityManager 的明确转变，对遗留 API 和模糊规范语言的更广泛清理，以及为现代 Web 协议如 HTTP/3 做准备。
由于OSSRH和 Maven Central 的后续新过渡协议的结束，一些规范无法提供里程碑 1 版本。因此，这些规范将直接进入里程碑 2，如本仪表板所示。
我们将重点关注四个可以提供里程碑2版本的规范：
Jakarta Query为持久层提供了一种通用的面向对象语言。
Jakarta Data支持对存储库的动态查询，并与 Jakarta Query 集成。
Jakarta Persistence支持 Java 21 中引入的 SequencedCollection 接口，以及与 Jakarta Query 的集成。
Jakarta NoSQL引入了带有 Java 记录的投影和与 Jakarta Query 的集成。
除了强大和灵活的新主题，我们可以将 Jakarta EE 12 称为数据时代，它包括 Jakarta EE 生态系统中的多语言持久性，使 Jakarta EE 能够“说”SQL 和 NoSQL，可能还包括 Jakarta NoSQL 1.1。
Jakarta Query
作为新批准包含在 Jakarta EE 12 平台和 Web 配置文件中的规范，Jakarta Query 1.0，初始版本，为持久层提供了一种 Java 查询语言。我们的目标是从 Jakarta Persistence 中提取 Jakarta 持久化查询语言（JPQL）和从 Jakarta Data 中提取 Jakarta 数据查询语言（JDQL），并将其集中到一个基于两种语言的单一规范中：
Jakarta 通用查询语言（JCQL），基本语言，你可以执行基本查询操作，这些操作可以与 Jakarta Data 和 Jakarta NoSQL 规范一起使用。
Jakarta 持久性查询语言（JPQL），一种扩展了核心语言的关系和实体特性的语言，用于 Jakarta 持久性规范和其他基于 SQL 的技术。
由于这是一个新规范，我们仍在进行一些需要改进的工作，包括规范及其组件中使用的术语。我们有的是定义一种由两个配置文件或语言组成的语言的规范。
核心语言是完整的 Jakarta 查询语言的一个子集，专注于可移植性操作，如选择、限制、排序和简单的投影。为了说明，考虑下面房间文档的 JSON 表示：
{ "id": "R-101", "type": "DELUXE","status": "AVAILABLE", "number": 42 }
使用核心语言，一个查询可能会检索所有可用的豪华房间，并按它们的号码排序：
FROM Room WHERE type = 'DELUXE' AND status = 'AVAILABLE' ORDER BY number
持久性语言是一种关系查询语言，它引入了面向 SQL 的结构，如连接、分组和批量更新或删除。这些在关系上下文中特别有用。例如，假设有一个嵌入了房间列表的酒店文档。
有了持久性语言，一个查询可以计算每个酒店的已入住客房数，只返回客房数大于 10 的客房：
SELECT h.name, count(r) FROM Hotel h JOIN h.rooms r WHERE r.status = 'OCCUPIED' GROUP BY h.name HAVING count(r) > 10 ORDER BY count(r) DESC
该规范的主要目标是作为持久性的参考语言。因此，它将被用于 Jakarta NoSQL、Jakarta Persistence 和 Jakarta Data。
Jakarta Data
Jakarta Data 1.0 是 Jakarta EE 11 中流行的新规范。该规范的最新版本Jakarta Data 1.1简化了 Java 和持久层之间的集成，允许你通过统一的接口同时使用 NoSQL 和关系数据库。这个新版本引入了三个新特性。
第一个特性允许你在存储库中执行动态查询。你可以使用 fluent API 创建搜索，给定可以包含在存储库中的 Restriction 属性。
@Repository public interface Products { List<Product> findAll(Restriction<Product> restriction); }
这个版本包含元模型上的更多功能，包括搜索的 fluent API 功能。因此，我们可以在仓库中组合限制：
@Inject private Products products;List<Product> found = products.findAll( Restrict.all( _Product.type.equalTo(ProductType.PHYSICAL), _Product.price.greaterThan(10.00f), _Product.name.contains("Jakarta") ) );
第二个特性是使用 @Is 注解改进的搜索。在 Jakarta Data 1.0 中，有按等值条件查询的选项。但在新版本中，你可以使用 @Is 注解或使用新的 Constraint 接口的实例：
List<Product> pricedBelow(@By(_Product.PRICE) @Is(LessThan.class) float max); @Find Page<Product> search( @By(_Product.NAME) @s(Like.class) String pattern, PageRequest pagination, Order<Product>; order); @Find List<Product> inSomeOtherRegionThan( @By(_Country.REGION) NotEqualTo<Region> exclude);
Jakarta 查询将用核心语言替换 Jakarta Data 中现在已废弃的 JDQL。目标是保持兼容性，这样就不会对 Jakarta EE 12 中的用户造成影响。
@Repository public interface BookRepository extends BasicRepository<Book, UUID> { // 查找书名与特定模式匹配的图书 @Query("WHERE title LIKE :titlePattern") List<Book> booksMatchingTitle(String titlePattern); // 按特定作者选择书籍，并按书名排序 @Query("WHERE author.name = :author ORDER BY title") List<Book> findByAuthorSortedByTitle(String author); }
Jakarta Data 最初默认使用无状态仓库。在这种方法中，每个操作都是一次处理一个，没有上下文或记忆在调用之间传递，保持简单、可预测，并清楚地表明每个事务的开始和结束。
在最新版本中，Jakarta Data 现在也支持有状态存储库。有了这种支持，你就可以使用持久化上下文，就像在 Jakarta 持久化规范中一样。有状态存储库让你管理实体的完整生命周期，比如保存、更新、刷新、分离和删除。你还可以利用延迟同步和延迟加载等特性。
@Repository public interface Products extends DataRepository<Product, String> { @Persist void add(Product product); @Merge Product merge(Product product); @Remove void remove(Product product); @Refresh void reload(Product product); @Detach void detach(Product product); }
Jakarta NoSQL
Jakarta NoSQL 1.1，这个规范的最新版本，促进了 NoSQL 和 Java 在企业 Java 中的轻松集成。这个版本的亮点是支持通过 Jakarta query 的核心语言特性的查询语言。这个版本将由与 Jakarta Persistence 类似的术语驱动，使 Java 开发者更容易在企业应用中使用 NoSQL 数据库。
Jakarta NoSQL 提供两个特性。第一个是新的 Query 接口，它提供了与 Jakarta Persistence 中已经存在的对应物类似的结构。这个接口将作为核心语言和 Jakarta NoSQL 规范之间的桥梁。Query 接口允许你动态设置参数，并返回单个结果作为 List 、 Stream 或 Optional 。
List<Car> cars = template.query("FROM Car WHERE type = :type") .bind("type", CarType.SPORT) .result();
新的 TypedQuery 接口允许你在查询中定义实体并将其作为实体本身返回，或者将其作为记录类定义的投影的新结构返回。
@Projection(from = Car.class) public record BudgetCar(String name, double price) { } List<BudgetCar> cheapCars = template .typedQuery("WHERE price < 100", BudgetCar.class) .result();
Jakarta Persistence
Jakarta Persistence 4.0，即该规范的最新版本，新增的一个特性是将 JPQL 转移到 Jakarta Query。Jakarta Persistence 是一个面向数据的规范，它仍将像以前一样使用 JPQL。这种语言将保持向后兼容性。因此，它不会影响可能仍在使用旧版本 JPQL 的 Java 开发人员。
Jakarta Persistence 还支持 Java 21，为新结构提供支持：
@Entity @Table(name = "orders") public class Order { @Id @GeneratedValue(strategy = GenerationType.UUID) private UUID id; @Column(nullable = false) private String customer; @Column(nullable = false) private Instant createdAt = Instant.now(); @ElementCollection @CollectionTable(name = "order_lines", joinColumns = @JoinColumn(name = "order_id")) @Column(name = "item") private SequencedCollection<String> items = new LinkedHashSet<>(); }
有一些关于在 Jakarta Data 中为静态查询添加注释的讨论。目标是提供更多的功能和选项来运行结合 Jakarta 数据和 Jakarta 持久性的查询。
@Repository interface Library { @StaticQuery("where title like :pattern") @ReadQueryOptions(cacheStoreMode=BYPASS) List<Book> books(String pattern); }
你可以在 IBM 的 Red Hat 高级杰出工程师Gavin King的博客文章中了解更多关于 Jakarta Persistence 4.0 的信息。
Jakarta 代理式人工智能
在 2025 年 11 月初，一项新的专注于采用人工智能的规范通过了创建审查。Jakarta Agentic AI规范提供了一套供应商中立的 API，旨在简化、标准化和简化在 Jakarta EE 运行时构建、部署和运营 AI 智能体的过程。
通过提供统一的方法，开发人员可以跨不同环境以更高的效率和一致性创建智能解决方案。
这些 API 将旨在促进互操作性和可靠性，使组织能够加速创新，同时保持灵活性和与行业最佳实践的一致性。
这项新规范的范围包括：
为在 Jakarta EE 运行时内运行的 AI 代理建立标准化的使用模式和生命周期，以促进互操作性和一致性。
提供访问基础 AI 能力的简化外观，例如大语言模型（LLM），而不是标准化 LLM 本身。API 提供直接、可插拔和可配置的集成，与现有的 LLM API（如 LangChain4j 和 Spring AI）集成，类似于 Jakarta Persistence 如何解包对底层非标准 API 的访问。
API 预计将包括一个流畅的 Java API，用于定义代理工作流，而不是 XML。这些工作流将在运行时动态，包含灵活的适应性，而不是依赖于部署时的静态定义。此外，可能还有通过 YAML 和 XML 等格式的可插拔性支持。
与重要的 Jakarta EE 规范建立集成。这些集成包括 Jakarta Validation、Jakarta RESTful Web Services、Jakarta JSON Binding、Jakarta Persistence、Jakarta Data、Jakarta Transactions、Jakarta NoSQL、Jakarta Concurrency、Jakarta Security 和 Jakarta Messaging。
该项目在可行的地方利用 Jakarta Config，并允许实现使用 MicroProfile Config。
实现还可能提供与 OpenTelemetry 的集成，以增强可观测性。
Jakarta Agentic AI 1.0，初始版本，有意最小化，以促进早期采用，促进社区参与，并提高对 Jakarta Agentic AI 倡议的认识。未来的增强将根据行业趋势和持续的用户和贡献者反馈进行指导，以使规范保持相关性和前瞻性。
这个版本集中在基础编程模型和最佳实践上，并引入了一个轻量级的外观，用于集成 LLM。后续版本预计将扩展程序生命周期管理，并为更高级的代理编排提供全面的工作流 API。
规范正在开发中，因此你可以通过参与规范过程并提供反馈和报告错误，通过电子邮件列表或直接在每个规范的 GitHub 存储库中，为最后阶段做出贡献。如果你想直接为代码做出贡献，但不知道如何做到这一点，还有Jakarta EE社区导师计划，你可以在那里学习如何直接为 Java 企业平台的代码做出贡献。
Jakarta EE 12 采用时间线
与任何软件开发过程一样，里程碑版本不打算在生产代码中使用；相反，它允许开发人员进行实验、测试和提供反馈。里程碑版本的目标与 OpenJDK 中的孵化和预览功能类似。
Jakarta EE 12 通过保持向后兼容性来兑现其主要承诺，这将使已经使用 Jakarta 持久性和 Jakarta 数据的组织受益。包括统一查询语言和更清晰的有状态与无状态存储库模型之间的界限在内的最新改进，将提供永久性的解决方案，以消除所有不确定领域。这些变化专注于通过使旧代码中发现的奇怪行为案例可见来增加透明度。当前阶段要求架构师和开发人员停止解决紧急问题，以便他们可以学习新定义将如何改变他们现有的工作方法。
要使 Jakarta EE 12 的采用变得广泛，工具将是决定性因素，特别是对于 Jakarta 查询和基于存储库的数据访问。当前开发阶段仍需要额外的工作来完成诸如 IDE 集成、查询验证、重构和运行时诊断等功能。当实现最终确定时，工具生态系统将发挥其全部能力。
结论
Jakarta EE 12 里程碑 2 定义了迈向最新企业级 Java 平台版本的第一步。通过开放和透明的贡献过程提供的机会，允许整个社区对规范提供反馈。Jakarta 查询的引入将数十年的查询演变，从 JPQL 到 JDQL，整合为一种单一的、可扩展的语言，连接了关系型和非关系型数据库的世界。Jakarta 数据、Jakarta 持久性和 Jakarta NoSQL 现在共享一个一致的查询基础，可以减少碎片化并改善整个生态系统中的开发人员体验。
以 Java 21 作为新的基线，Jakarta EE 继续其拥抱现代 Java 语言特性的传统，提供改进的性能、更清晰的语法和长期的可维护性。虽然这个里程碑标志着 Jakarta EE 12 旅程的开始，但它已经表明了一个明确的方向：规范之间的更紧密集成、提高开发人员生产力，以及与核心 Java 平台的更强大的对齐。
第三和第四个里程碑将完善理念，稳定 API，并增加兼容性。
原文链接：
