将 脚本之家 设为“星标⭐”
第一时间收到文章更新
来源 | xxy开源 （ID：xxyopen）
在软件系统的演进过程中，随着业务规模扩大和架构复杂度提升，数据访问层往往最先变得“失控”。
我们不仅要面对 多种数据库（关系型、文档型、图数据库、宽列存储等），还必须同时适应 多种查询模型：
•SQL 的 JOIN•文档数据库的嵌套与投影•图数据库的遍历•宽列数据库的集合操作•……
对 Java 开发者 而言，这并不只是“多学几种语法”，而是一种长期存在的 隐性成本：
•查询逻辑难以复用•持久化层与数据库强绑定•数据库迁移代价极高
为了解决这个问题，Jakarta EE 12[1]（2026 年 5 月 31 日 发布） 引入了 Jakarta Query[2]，试图：
用一套统一的、面向对象的查询语言，同时覆盖关系型数据库和非关系型数据库。
如果成功，这将显著降低企业级 Java 应用在持久化层的复杂度。
Jakarta EE 是 Java 在企业级应用领域的官方标准平台，前身是大家熟悉的 Java EE。
很多开发者并不直接使用 Jakarta EE，但却 每天都在间接使用它。
以 Spring Boot 4 为例，它已经全面基于 Jakarta EE 11 构建：
•javax.* 命名空间已彻底迁移为 jakarta.*•Servlet、JPA、Bean Validation、Transactions 等核心能力，本质上都来自 Jakarta EE 规范
Spring 并未替代 Jakarta EE，而是 选择性地实现并扩展其规范。
可以说：
Jakarta EE 定义标准，Spring Boot 负责落地与工程化。
Jakarta Query 是 Jakarta EE 12 中提出的一项 全新规范，目的是统一以下技术栈中的查询语言：
•Jakarta Persistence（JPA）•Jakarta Data•
Jakarta NoSQL
它并不是要 重新发明轮子，而是试图 收敛已有的查询语言体系，避免并行演进带来的割裂。
核心目标可以总结为一句话：
一次编写查询，在 SQL 与 NoSQL 之间可移植执行。
Java 生态并不缺查询语言：
•HQL（Hibernate Query Language）•EJB-QL•JPQL（2006 年标准化）•JDQL（Jakarta Data Query Language）
问题不在于 没有标准，而在于：
同源而分裂，各自演进。
•JPQL 服务于关系型数据库•JDQL 服务于非关系型数据库
两者语义相似，却由不同规范维护。
Jakarta Query 的出现，本质上是一次 技术债清算：
•成为所有持久化规范的 公共查询层•被 Jakarta Persistence、Jakarta NoSQL、Jakarta Data 共同依赖•支持 关系型数据库、NoSQL、未来的图数据库、其他模型
尽管如此，Jakarta Query 并没有采用 一刀切 的设计，而是引入了分层模型：
1. 核心语言（Core Language）
•最小公共子集•服务于非关系型数据
•面向 Jakarta Data 与 Jakarta NoSQL•提供最小但通用的查询能力
2. 扩展语言（Extended Language）
•覆盖关系型数据库的完整查询能力•面向 Jakarta Persistence•与 JPQL 高度对齐
这种设计的关键价值在于：
•保持向后兼容•避免破坏现有 JPA / JPQL 生态•为未来统一演进预留空间
Jakarta Query 很可能是：
Jakarta EE 12 中最具颠覆性的变化。
更重要的是：
它由 Java 生态中最了解 ORM 与查询的 Gavin King（Hibernate 作者、JPA 核心人物）领导并推动。
从 JDBC → JPA → Jakarta Data → Jakarta Query， 企业级 Java 的持久化体系，正在从 框架林立、各自为战，走向：
多数据库支持 + 统一抽象 + 统一查询语言。
这不是一次简单的 API 更新，而是一次 理念层面 的升级。
References
[1] Jakarta EE 12: https://projects.eclipse.org/projects/ee4j.jakartaee-platform/releases/12/plan
[2] Jakarta Query: https://jakarta.ee/specifications/query/1.0
