雅加达-EE-12-Milestone-2：数据时代的到来与一致性及配置问题

关键要点

Jakarta EE 12将重点关注集成性、现代化改造、配置一致性以及提升开发人员的生产力。
Jakarta Query是Jakarta EE平台中的新规范，它将作为持久化层的统一编程语言。该规范会将Jakarta Persistence Query Language与Jakarta Data Query Language整合为一种统一的规范。
更新后的Jakarta Data、Jakarta Persistence以及Jakarta NoSQL版本都将能够与Jakarta Query实现集成。
Jakarta NoSQL提供了一种新的查询接口，这种接口与Jakarta Persistence中的类似接口相同，可以动态设置参数，并以List、Stream或Optional的形式返回结果。
一个新的规范——Jakarta Agentic AI——已经通过了制定阶段的审查，最终将会提供一套与供应商无关的API，这些API旨在简化在Jakarta EE运行时环境下构建、部署及运营AI代理的过程。

在2025年6月Jakarta EE 11发布之后，Jakarta EE 12的开发工作就已经全面展开，预计这一新版本将会在集成性方面带来改进，并与它的前身保持一致性。

Jakarta EE 12的第二个里程碑版本计划于2026年第一季度发布。在本文中，我们将介绍那些能够提升平台一致性及配置灵活性、从而改善Jakarta EE开发人员使用体验的新功能与特性。此外，我们还会重点介绍该平台上已经启动的一些初期项目。

为什么这个版本对开发人员和架构师来说如此重要

当我们谈论Java平台本身时，Jakarta EE 12的第二个里程碑版本实际上是对整个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平台的重要组成部分：

图1：Jakarta EE平台中的规范内容

需要特别注意的是，Jakarta MVC 3.1和Jakarta NoSQL 1.1的规范目前也在考虑是否被纳入Jakarta EE 12平台中。

在Jakarta EE 11版本中，Java 17被作为基准技术得到应用，同时也对Java 21提供了支持。这一设计使得开发者可以在Jakarta Persistence规范中使用Java记录作为嵌入类或ID，在Jakarta Concurrency规范中使用虚拟线程。而对于Jakarta EE 12来说，基准技术将是Java 21，并且也会支持Java 25。从平台层面来看，这一版本标志着人们正式告别了已经过时的SecurityManager，对众多老旧API进行了优化处理，同时也改进了那些表述模糊的规范语言，为支持HTTP/3等现代Web协议做好了准备。

由于OSSRH的终止，以及Maven Central随后采用的新测试部署机制，某些规范无法按照原计划发布Milestone 1版本。因此，这些规范将直接进入Milestone 2阶段，具体情况请参见这个仪表盘。

我们将重点关注四个能够发布Milestone 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 Profile的新规范，Jakarta Query 1.0为持久化层提供了一种Java查询语言。其目标是将Jakarta Persistence中的JPQL语言与Jakarta Data中的JDQL语言整合起来，形成一种基于这两种语言的统一规范：

Jakarta Custom Query Language (JCQL)是一种基础查询语言，可用于Jakarta Data和Jakarta NoSQL规范。
Jakarta Persistence Query Language (JPQL)则在JCQL的基础上增加了关系型和实体型查询功能，适用于Jakarta Persistence规范及其他基于SQL的技术。

由于这还是一项新规范，我们仍在对其中的一些内容进行改进，包括规范中使用的术语及其各个组成部分。目前我们已经有了一套定义这种由两种语言构成的统一规范的方案。

“核心语言”是Jakarta Query语言的子集，主要涵盖了选择、筛选、排序和简单数据投影等基本操作功能。举个例子，以下这个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数据库和关系型数据库。这个新版本引入了三项新功能。

第一项功能允许在数据存储库中执行动态查询。你可以利用流畅的API来实现搜索操作，同时还可以在数据存储库中设置相应的限制条件。

@Repository
public interface Products {
    List findAll(Restriction restriction);
}

这个版本在元模型方面提供了更多功能，包括使用流畅的API进行搜索。因此，我们可以在数据存储库中组合多种限制条件来进行查询：

@Inject
private Products products;

List 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 pricedBelow(@By(_Product.PRICE) @Is(LessThan.class) float max);

@Find
Page search(@By(_Product.NAME) @s(Like.class) String pattern,
    PageRequest pagination,
    Order> order);

@Find
List inSomeOtherRegionThan(@By(_Country.REGION) NotEqualTo exclude);

Jakarta Query将取代Jakarta Data中现已被弃用的JDQL，转而使用核心语言来进行数据操作。这样做的目的是为了保持兼容性，确保对使用Jakarta EE 12的用户不会产生任何影响。

@Repository public interface BookRepository extends BasicRepository {


    // 查找标题符合特定模式的书籍

    @Query("WHERE title LIKE :titlePattern")

    List booksMatchingTitle(String titlePattern);

// 按作者筛选书籍并按标题排序 @Query("WHERE author.name = :author ORDER BY title") List(Book> findByAuthorSortedByTitle(String author); }

Jakarta Data最初默认使用无状态仓库模式。在这种模式下，每个操作都是独立处理的，调用之间不会保留任何上下文信息或内存数据，这样的设计使系统更加简单、易于预测，并且能够清楚地判断每笔交易的开始和结束时间。


@Repository
public interface Products extends DataRepository {
    @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是这一规范的最新版本，它使得在企业级Java应用中集成NoSQL数据库变得非常方便。这一版本的亮点在于支持通过Jakarta Query的核心语言功能来执行查询操作。由于其术语体系与Jakarta Persistence相似，因此Java开发人员可以更加轻松地在企业级应用中使用NoSQL数据库。

Jakarta NoSQL提供了两项重要功能。首先是新的Query接口，该接口的结构与Jakarta Persistence中已有的对应接口类似。这个接口充当了核心语言与Jakarta NoSQL规范之间的桥梁，允许你动态设置查询参数，并将查询结果以List、Stream或Optional的形式返回。

List 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 cheapCars = template
  .typedQuery("WHERE price < 100", BudgetCar.class)
  .result();

Jakarta Persistence

Jakarta Persistence 4.0这一最新版本引入的一项新功能是将JPQL语言转换为Jakarta Query语言。Jakarta Persistence仍然会使用JPQL，这与它在使用Jakarta Data时的做法一致；这种语言设计保证了向后兼容性，因此不会影响那些仍在使用旧版JPQL的Java开发者。

Jakarta Persistence还支持Java 21规范，从而能够支持新的数据结构：

@Entity
@Table(name = "orders")
public class Order {
  @Id
  @GeneratedValue(strategy = GenerationTypeUUID)
  private UUID id;
  @Column(nullable = false)
  private String customer;
  @Columnnullable = false)
  private Instant createdAt = Instant.now();
  @ElementCollection
  @CollectionTable(name = "order_lines",
                    joinColumns = @JoinColumn(name = "order_id"))
  @Column(name = "item")
  private SequencedCollection items = new LinkedHashSet<>();
}

目前有人正在讨论是否应该在Jakarta Data中添加用于静态查询的注解，这样就可以为结合使用Jakarta Data和Jakarta Persistence来执行查询提供更多功能与选项。

@Repository
interface Library {
  @StaticQuery("where title like :pattern")
  @ReadQueryOptions(cacheStoreMode=BYPASS)
  List books(String pattern);
}

你可以通过Gavin King这篇博文，了解更多关于Jakarta Persistence 4.0的信息。Gavin是IBM的红帽高级杰出工程师。

Jakarta Agentic Artificial Intelligence

2025年11月初，一项专注于人工智能应用的新规范通过了审批。Jakarta Agentic AI规范提供了一套与供应商无关的API，这些API旨在简化、标准化以及优化在Jakarta EE运行时环境中构建、部署及运营人工智能代理的过程。

通过这种统一的开发方式，开发者能够在不同的环境中更高效、更一致地创建智能解决方案。

这些API的设计旨在促进互操作性和可靠性，使各组织能够在保持灵活性并遵循行业最佳实践的前提下加速创新进程。

这一新规范的范围包括以下内容：

为在Jakarta EE运行时环境中运行的AI代理建立标准化的使用模式和生命周期，从而提升各类实现的互操作性及一致性。
提供简洁的接口来访问基础的人工智能功能，例如大型语言模型，但并不要求对这些模型本身进行标准化处理。该API能够以直观、可插拔且可配置的方式与现有的LLM API（如LangChain4j和Spring AI）进行集成，其工作原理类似于Jakarta Persistence对非标准底层API的封装方式。
预计该API会采用Java语言来定义代理的工作流程，而非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作为初始版本，其设计初衷就是保持简洁性，以此促进早期应用、激发社区参与热情，并提升人们对这一项目的认知度。后续的升级版本将结合行业发展趋势以及用户和贡献者的反馈来进行优化，以确保该规范始终具有实用性和前瞻性。

这个版本主要聚焦于基础编程模型和最佳实践，并提供了用于集成LLM的轻量级接口。未来的版本预计会进一步扩展对程序化生命周期的管理功能，并提供更完善的工作流程API，以支持更高级别的代理协调工作。

该规范目前仍处于开发阶段，因此你可以通过参与规范制定过程、提供反馈或通过邮件列表或直接在各规范对应的GitHub仓库中报告错误来为最终版本的完善做出贡献。如果你想直接参与代码开发但不知道从何入手，还可以参加Jakarta EE社区导师计划，在那里你将学习如何在Java企业平台上进行代码开发工作。

Jakarta EE 12的采用时间表

与任何软件开发过程一样，里程碑版本的发布并不是为了在生产环境中直接使用；它的目的是让开发人员能够进行实验、测试并提供反馈。里程碑版本发布的意义，与OpenJDK中提供的试验性功能或预览版类似。

Jakarta EE 12通过保持向后兼容性，兑现了其核心承诺，从而为那些已经在使用Jakarta Persistence和Jakarta Data的工具和组织带来了好处。最近所做的改进，包括统一查询语言以及明确区分有状态与无状态的数据库模型，这些措施都有效消除了各种不确定性。这些变更的重点在于提高代码的透明度，让人们能够更容易地发现旧代码中存在的异常行为。在当前这个阶段，架构师和开发人员需要暂时停止解决那些紧急问题，以便了解新的技术规范将如何改变他们现有的工作方式。

要想让Jakarta EE 12得到广泛采用，工具的支持将是决定性因素，尤其是在处理查询操作和基于数据库的数据访问功能时。目前，这一开发阶段仍需进一步努力，才能完善IDE集成、查询验证、代码重构以及运行时诊断等功能。只有当这些工具真正成熟之后，整个工具生态系统才能发挥出其全部潜力。

结论

Jakarta EE 12的第二个里程碑标志着迈向这一企业级Java平台新版本的第一个步骤。通过开放和透明的贡献机制，整个社区都能够对相关技术规范提出反馈意见。Jakarta Query的引入，将多年来从JPQL到JDQL的发展历程整合成了一种统一且可扩展的查询语言，这种语言能够同时支持关系型数据库和非关系型数据库。现在，Jakarta Data、Jakarta Persistence以及Jakarta NoSQL都共享着统一的查询基础，这一设计有助于减少技术碎片化现象，进而提升整个开发生态系统的效率。

以Java 21作为新的基准，Jakarta EE继续秉承着拥抱现代Java语言特性的传统，从而提供了更优异的性能、更简洁的语法以及更高的长期可维护性。虽然这个里程碑标志着Jakarta EE 12发展的起点，但它已经指明了明确的发展方向：各技术规范之间将实现更加紧密的整合，开发人员的效率也会得到进一步提升，同时，Jakarta EE与核心Java平台的融合程度也会进一步加强。

接下来的第三和第四个里程碑将进一步完善各项功能，稳定API接口，并提升兼容性。