Jakarta EE 12：企业Java踏入数据时代

数十年来，Jakarta EE 一直在应对构建能够承受技术变革的企业系统的挑战。该平台从单体架构演进到微服务，从应用服务器演进到 Kubernetes，从关系数据库演进到分布式数据平台，同时始终保持着其核心优势：兼容性。Jakarta EE 12 标志着又一次重大转型，将关注点从云原生基础设施和 API 转向优先考虑数据。现代企业系统现在运行在多样化的环境中，这些环境已超越关系数据库和同步 CRUD 应用。当前的架构整合了 SQL、文档数据库、图引擎、键值存储、事件流、向量数据库以及 AI 驱动的工作流。主要挑战在于提供一个统一的编程模型，以管理碎片化的数据生态系统，同时避免供应商锁定或频繁的应用重写。Jakarta EE 12 通过将查询、数据访问、初始化和语义一致性提升为平台级关注点来解决这一问题。此次发布标志着企业 Java “数据时代”的开端。这一演进的核心是 Jakarta Query，一个统一的语义查询模型，它通过公共抽象连接 Jakarta Persistence、Jakarta Data 和 Jakarta NoSQL。Jakarta EE 12 没有让每个规范定义自己的查询语义，而是引入了一种跨多种持久化技术共享的语言，同时支持专门的执行模型。这一架构转变减少了生态系统碎片化，并为多语言持久化系统提供了更一致的开发者体验。

Jakarta EE 12 还扩展了传统的依赖注入和请求处理。CDI 现在提供了更可预测的启动和生命周期管理，这对于云原生部署、无服务器运行时、AI 编排和基于代理的架构至关重要。以 Java 21 作为新的平台基线，Jakarta EE 被定位为一个现代化平台，在数据和 AI 驱动的世界中支持长期运行的适应性系统。本文将探讨 Jakarta EE 12 如何通过 Jakarta Query、Jakarta Data、Jakarta NoSQL、CDI 5.0、Persistence 4.0 以及 Jakarta Agentic AI 等新举措来改造企业 Java 生态系统。我们还将讨论这些规范如何形成一个统一的平台战略，在简化企业开发的同时，保持使 Java 成为领先软件生态系统的稳定性和互操作性。

企业复杂性的演进

软件架构一直在为解决复杂性而演进。最初，组织依赖于集中式大型机，其中应用程序、基础设施和数据位于单一环境中。向客户端-服务器和三层模型的转变引入了分布式系统，将表示层、业务逻辑层和持久化层分离到不同的层中。如今，云原生系统跨越集群、分布式网络、容器、Kubernetes、边缘设备和全球复制的数据库。现代企业软件作为一个互联服务的生态系统运行，这些服务部署在开发者可能无法完全控制的基础设施上。这种演进显著增加了对软件工程师和架构师的认知要求。当今的技术格局包括大量框架、运行时、数据库、API、消息系统、编排平台和 AI 驱动工具。开发者体验已成为一个竞争激烈的市场，各种平台都承诺提供生产力、简单性和可扩展性。工程师必须不断在性能、一致性、可扩展性、运维复杂性和供应商锁定之间权衡利弊。行业还面临着“炒作效应”，即技术在长期影响尚未完全理解之前就获得流行。

随着系统变得越来越分布式，架构风格也层出不穷。传统的分层架构现在与微服务、事件驱动系统、CQRS、编排平台、微内核和领域驱动设计并存。每种风格都针对特定的挑战。微服务增强了部署独立性，事件驱动系统提高了可扩展性和弹性，CQRS 管理复杂的读写工作负载。然而，这种多样性导致了碎片化。开发者现在不仅需要掌握编程语言和框架，还需要理解分布式系统理论、一致性模型、可观测性、容错性、异步通信和运维自动化。

数据复杂性也类似地演进。几十年来，企业应用主要依赖关系数据库和 SQL。如今，组织使用文档数据库、图数据库、键值存储、宽列引擎、流处理系统、向量数据库以及这些的组合。这种被称为多语言持久化的趋势反映了不同数据模型满足不同业务需求的事实。例如，推荐引擎可能需要图遍历，金融系统依赖事务一致性，而 AI 系统越来越多地使用向量相似性搜索。因此，企业开发现在已超越编写业务逻辑本身。工程师必须管理分布式架构、多种持久化模型、云原生基础设施、安全性、异步通信，以及日益增多的 AI 驱动工作流。在这种环境中，标准至关重要。不断增长的复杂性使得碎片化成为一个重大的长期风险。如果没有公共抽象和可互操作的 API，组织将面临昂贵的迁移、供应商锁定和运维不稳定。Jakarta EE 12 正是为了应对这些挑战。该平台没有将持久化、查询、依赖注入和运行时行为视为独立的关注点，而是针对现代分布式系统采用了一种统一模型。其目标并非消除架构多样性，而是提供一个稳定且一致的基础来支持这种多样性。

为什么 Jakarta EE 依然重要

企业 Java 已经发展了近三十年。Java EE 诞生于 20 世纪 90 年代末，旨在在碎片化的专有技术格局中标准化企业应用开发。该生态系统从 J2EE 演进到 Java EE，再到如今 Eclipse 基金会下的 Jakarta EE。每一次转型都映射出更广泛的行业变革，包括 Web 应用、分布式系统、云原生计算和 AI 驱动架构的出现。Java 在企业环境中的主导地位不仅仅源于语言本身。它的成功在于将两个很少共存的因素结合在一起：开放标准和开源。许多生态系统只提供其中之一。有些是开源的，但缺乏治理和互操作性。另一些提供了标准，但演进缓慢或与开发者需求脱节。Jakarta EE 弥合了这两个世界，既提供了规范驱动的一致性，也提供了开源的创新。从历史上看，标准对于人类可扩展性至关重要。共享语言实现了合作，书写系统保存了知识，而像公制这样的标准单位支持了全球贸易和科学。软件也面临类似的挑战。随着系统扩展和团队变得更加分散，共享抽象和互操作性变得至关重要。标准减少了歧义，改善了团队沟通，并允许技术在不频繁重写的情况下演进。这在企业环境中尤其重要，因为系统通常比用于构建它们的技术寿命更长。

企业应用程序很少被重写。银行、政府、医疗机构、航空公司和零售商运行的系统可能持续数十年，同时在其内部演进。在这种背景下，开放标准和开源是战略选择。它们减少了运维锁定，提高了供应商可移植性，支持长期运行的系统，并能够实现增量现代化而非冒险的重写。Jakarta EE 通过不强加单一架构、运行时或部署模型来满足这些需求。该平台支持单体、模块化系统、微服务、响应式架构和云原生部署。它与现代框架和运行时无缝集成，包括许多开发者日常使用的那些人，他们往往没有意识到 Jakarta EE 规范正是这些技术的基础。像 Spring、Quarkus、Micronaut、Hibernate、Tomcat 和 Payara 这样的技术直接实现、扩展或依赖于 Jakarta EE 规范。正是这一点使得 Jakarta EE 在今天格外相关。在一个充斥着快速变化的框架和基础设施趋势的市场中，Jakarta EE 提供了稳定而不停滞。该平台深思熟虑地演进，在保持兼容性的同时适应新的现实，如云原生计算、多语言持久化和 AI 驱动系统。Jakarta EE 11 奠定了现代化基础，例如 Jakarta Data 等规范。Jakarta EE 12 在此基础上构建，将企业 Java 带入可被称为数据时代的阶段。

Jakarta EE 12 与统一数据访问的兴起

Jakarta EE 12 的一个关键变化是承认数据访问不能再局限于关系数据库。现代企业应用现在跨越 SQL 数据库、NoSQL 引擎、分布式缓存、事件流和 AI 关注的数据存储。主要挑战已从单纯的持久化转向确保跨不同数据系统的一致开发者交互。Jakarta EE 12 通过引入用于查询和数据访问的统一语义模型来解决这一问题。其核心是 Jakarta Query，一个新的抽象层，作为 Jakarta Persistence、Jakarta Data 和 Jakarta NoSQL 的公共查询基础。不是每个规范定义各自的查询语义，Jakarta Query 提供了一种共享语言，用于跨多种持久化技术进行过滤、排序、限制和查询组合。

企业 Java 经历了若干代查询语言的演进，从 JDBC 的直接 SQL 关注到 JPA 的 JPQL 以及各种框架特定的抽象。这些独立的发展导致了碎片化。Jakarta EE 12 试图通过将语义意图与执行策略分离来解决这个问题，使开发者能够使用通用的查询概念模型，同时允许每种技术根据需要进行优化执行。这在多语言持久化架构中尤为重要。关系数据库优化连接和事务，文档数据库提供模式灵活性，图数据库强调关系遍历。Jakarta Query 并未消除这些差异，但提供了一种跨技术的一致开发者体验，减少了对供应商特定 API 的依赖。

Jakarta Data 1.1 以其流畅、类型安全的查询模型体现了这种方法。开发者可以在 Java 中动态组合使用语义限制和排序规则的查询，而不是依赖基于字符串的查询构造。

List<Product> found = products.findAll(
    Restrict.all(
        _Product.type.equalTo(ProductType.PHYSICAL),
        _Product.price.greaterThan(10.00f),
        _Product.name.contains("Jakarta")
    ),
    Order.by(
        _Product.price.desc(),
        _Product.name.asc()
    )
);

这种方法增强了可读性，并减少了基于字符串的查询语言中常见的运行时查询错误。更重要的是，它使查询与领域模型保持一致，支持领域驱动企业应用的一个核心原则。

Jakarta Data 1.1 还将仓库模型扩展到基本 CRUD 操作之外。有状态仓库现在在其抽象中包含了面向生命周期的操作，例如 persist、merge、refresh、detach 和 remove。

@Repository
public interface Products extends DataRepository<Product, Long> {
    @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 EE 12 正在引导企业 Java 走向一个统一的数据平台。该平台不再要求开发者在不同持久化技术之间切换思维模型，而是统一了应用如何表达查询、过滤、生命周期管理和数据交互的意图。随着分布式系统和多语言持久化变得越来越普遍，这种语义一致性可能成为企业 Java 的一个关键架构优势。

视频 3

DZone 贡献者所表达的意见属于其个人观点。