你好，欢迎来到《JavaEE企业级架构深度进阶》专栏的第一篇。
在正式开始之前，我想先问你一个问题：你平时用 Spring Boot 写项目，但你有没有想过------你写的代码到底是在"遵循什么标准"？
如果你脱口而出"JavaEE"，那恭喜你，方向对了。但如果你说"Spring Boot就是JavaEE"，那这篇文章就是为你准备的。
很多人用了几年 Spring，却始终分不清"框架"和"规范"的区别。这就像你会开车，但不知道交通规则是谁制定的------不影响你日常通勤，但一旦遇到复杂的路况（比如面试官问你"Servlet 和 DispatcherServlet 是什么关系"），你就容易翻车。
这一篇，我们不写代码，先打好认知的地基。
学习目标
- 理解 JavaEE 的定位------它不是一个框架 ，而是一套企业级开发规范
- 掌握 JavaEE → Java EE → Jakarta EE 的名称演变脉络及背后的商业故事
- 厘清 JavaEE 规范体系包含哪些核心规范（Servlet、JSP、EJB、JPA、JTA 等）
- 理解 JavaEE 与 Spring 框架的关系：Spring 是对 JavaEE 规范的补充与简化
正文
一、从 JDK 到 J2EE：企业级扩展的"独立宣言"
时间回到 1995 年，Java 刚刚诞生。那时候的 Java 还只是一个"小程序语言"，用来在网页上跑一些动画和交互（Applet）。
但随着 Java 越来越受欢迎，企业级应用开发的需求开始浮现------需要连接数据库、需要处理分布式事务、需要构建 Web 应用。于是，Sun 公司开始在 JDK 中逐步加入企业级扩展功能。
但问题很快就来了：JDK 的定位是"通用编程语言的标准库"，如果把企业级功能全部塞进去，JDK 会变得臃肿不堪，而且企业级功能迭代速度远快于 JDK 本身。
于是，1999 年，Sun 公司做出了一个关键决策：把企业级扩展从 JDK 中剥离出来，形成一个独立的平台 ------这就是 J2EE（Java 2 Platform, Enterprise Edition）的诞生。
你可以这样理解：JDK 是"基础工具箱"，里面有扳手、螺丝刀；J2EE 是"建筑工程规范"，告诉你盖一栋楼应该用什么标准、什么材料。
J2EE 1.2 于 1999 年 12 月正式发布，由 WebLogic 和 iPlanet（后来的 Sun ONE）等应用服务器率先实现。从此，企业级 Java 开发有了第一套"官方标准"。
二、J2EE → Java EE → Jakarta EE：三次更名背后的故事
这个名称演变过程，很多开发者搞不清楚。我们来逐一拆解。
第一次更名：J2EE → Java EE（2006 年）
2006 年，随着 Java 5 的发布，Sun 公司做了一次品牌梳理。"J2EE"这个名字中的"2"代表的是 Java 2 平台，但 Java 5 发布后，"Java 2"这个说法已经被淘汰了。
于是，J2EE 被更名为 Java EE （Java Platform, Enterprise Edition）。这次更名只是品牌层面的调整，技术内核没有本质变化。
第二次更名：Java EE → Jakarta EE（2017---2018 年）
这才是真正"伤筋动骨"的一次。
2017 年 9 月，Oracle 宣布将 Java EE 的相关权利转让给 Eclipse 基金会。Java 语言本身仍然归 Oracle 所有。
这里有个关键细节：Oracle 不允许 Eclipse 基金会继续使用"Java"这个商标。原因很简单------商标保护策略，防止 Java 品牌被稀释。
于是，Eclipse 基金会必须为这个平台重新起名。2018 年 2 月，社区发起了投票，近 7000 名社区成员参与，超过 64% 的人投票支持"Jakarta EE" 。有趣的是，"Jakarta"这个名字原本是 Apache 软件基金会旗下 Jakarta 项目使用的名称，2011 年该项目退役后，Apache 允许 Eclipse 基金会重新使用这个名字。
2018 年，Java EE 正式更名为 Jakarta EE。
第三次变化：从 javax 到 jakarta（Jakarta EE 9 起）
更名之后，还有一个更"疼"的变化------包名迁移。
在 Java EE 时代，所有 API 的包名都以 javax.* 开头（如 javax.servlet、javax.persistence）。但 Eclipse 基金会不能在新规范中使用 javax 包名创建新的 Java 包，因为 Oracle 拥有 javax 商标的使用权。
于是，从 Jakarta EE 9 开始，所有 API 的包名从 javax.* 迁移到了 jakarta.* 。这意味着：
javax.servlet.HttpServlet→jakarta.servlet.http.HttpServletjavax.persistence.Entity→jakarta.persistence.Entity- 所有
import语句、配置文件中的类引用，都要改
这个变化是单向的、不可逆的 ------一旦升级到 Jakarta EE 9+，就无法再回到 javax 命名空间。这也是 Spring Boot 3.x 升级中最大的"破坏性变更"之一。
三、什么是"规范"？------规范和实现的关系
在继续往下之前，我们必须把"规范"这个概念彻底搞清楚。
规范（Specification）是一套接口定义、行为约定和约束条件，它只告诉你"应该做什么"和"应该长什么样"，但不告诉你"具体怎么做"。
举个例子：
- Servlet 规范 定义了
HttpServlet类应该有doGet()、doPost()方法，但不实现这些方法如何处理具体的网络请求 - Tomcat 是 Servlet 规范的一个实现------它真正去监听端口、解析 HTTP 请求、调用你的 Servlet 代码
- 就像 JDBC 规范 定义了
Connection、Statement接口，但MySQL 驱动 和Oracle 驱动才是真正的实现
规范 = 接口，实现 = 实现类。
你可以同时有多个实现：Tomcat、Jetty、Undertow 都是 Servlet 规范的实现。它们遵循同一套规范，所以你的代码在任何容器中都能运行------这就是规范的价值：可移植性。
补充：JavaEE/Jakarta EE 本身不是一个"软件"或"框架"，而是一组规范的集合。Eclipse GlassFish 是 Jakarta EE 平台的官方参考实现，但生产环境中更常见的是 WildFly、WebLogic、WebSphere 等商业或开源实现。
四、JavaEE 规范全景图
那么，JavaEE/Jakarta EE 到底包含哪些规范？
以下是 Jakarta EE 平台中最核心的规范（部分），你可以按"分层"的方式来理解：
| 分层 | 核心规范 | 主要职责 | 最新版本（Jakarta EE 11） |
|---|---|---|---|
| Web 层 | Jakarta Servlet | 处理 HTTP 请求/响应 | 6.1 |
| Jakarta Server Pages (JSP) | 动态生成 HTML 页面 | 3.1 | |
| Jakarta Expression Language (EL) | JSP/JSF 中的表达式语言 | 5.0 | |
| Jakarta WebSocket | WebSocket 通信 | 2.2 | |
| 业务层 | Jakarta Enterprise Beans (EJB) | 分布式业务组件（重量级） | 4.0 |
| Jakarta Contexts & Dependency Injection (CDI) | 依赖注入（轻量级） | 4.1 | |
| Jakarta Transactions (JTA) | 分布式事务管理 | 2.0 | |
| Jakarta Concurrency | 并发工具 | 3.1 | |
| 数据层 | Jakarta Persistence (JPA) | ORM 规范（Hibernate 是实现） | 3.2 |
| Jakarta Data | 简化数据访问（Jakarta EE 11 新增） | 1.0 | |
| Jakarta Bean Validation | 数据校验（Hibernate Validator 是实现） | 3.1 | |
| 其他 | Jakarta RESTful Web Services | REST API（JAX-RS 的继任者） | 3.2 |
| Jakarta JSON Processing | JSON 解析与生成 | 2.1 | |
| Jakarta Security | 安全认证与授权 | 3.0 |
Jakarta EE 11 在 2025 年 6 月 26 日正式发布，带来了 1 项新规范（Jakarta Data）和 16 项更新规范 。它要求 Java 17 作为最低版本，并为 Java 21 的虚拟线程（Virtual Threads）和 Record 等特性提供了专门增强。目前 Jakarta EE 12 已经在规划中，预计 2026 年发布，将把 API 源码级别提升到 Java SE 21。
如果你现在用的是 Spring Boot 3.x，它基于 Jakarta EE 9/10。而 Spring Boot 4.0 将把基线提升到 Jakarta EE 11------所以理解 Jakarta EE 的演进，对你后续的框架升级也至关重要。
五、Spring 与 JavaEE 的关系：不是替代，而是"封装 + 增强"
这是全篇最重要的认知------Spring 不是替代 JavaEE，而是对 JavaEE 规范的补充和简化。
让我们回到 2003---2004 年。那时候的企业 Java 开发，主流方案是 EJB 2.x。EJB 是 JavaEE 规范的一部分，但它的设计非常"重量级"------你需要写大量的接口、配置文件，部署流程复杂，而且离不开昂贵的应用服务器（WebLogic、WebSphere）。
Rod Johnson （Spring 的创始人）在 2003 年出版了《Expert One-on-One J2EE Development without EJB》一书，提出了一个观点：企业级开发可以更简单。他随后创建了 Spring 框架。
Spring 的核心思路是：
- 拥抱 JavaEE 规范，但不被规范绑架------Spring 集成了 Servlet、JPA、JTA 等规范，但提供了更简洁的 API
- 用 IoC 容器管理对象，替代 EJB 的复杂生命周期管理
- 用 AOP 实现声明式事务，替代 EJB 的容器管理事务（CMT）
- 用 POJO（Plain Old Java Object）编程，替代 EJB 对特定接口的继承要求
你可以这样理解两者的关系：
| 维度 | JavaEE/Jakarta EE | Spring |
|---|---|---|
| 本质 | 一套规范（接口定义） | 一个框架（具体实现 + 扩展） |
| 谁制定的 | Eclipse 基金会（原 Sun/Oracle） | Pivotal/Broadcom（社区驱动） |
| 提供什么 | API 定义 + 兼容性标准 | 开箱即用的功能 + 最佳实践 |
| 关系 | "交通规则" | "带导航的高性能汽车" |
| 典型场景 | 应用服务器兼容性、标准化需求 | 绝大多数企业级 Web 应用 |
用一句话总结：JavaEE 定标准，Spring 让标准更好用。
这也解释了为什么你在日常开发中几乎感受不到 JavaEE 的存在------因为 Spring 把那些复杂的规范 API 都封装好了。你写 @RestController 的时候，底层是 Servlet 规范；你写 @Transactional 的时候，底层是 JTA 规范。你享受了规范的便利，却不需要直面规范的复杂度------这就是 Spring 的价值。
但反过来说，如果你完全不懂规范，你就无法真正理解 Spring 的设计动机，遇到问题也只能"搜答案"而无法"推原因"。这也是为什么我们要从 JavaEE 开始讲起。
代码示例
第一篇不涉及代码实现，但我建议你动手做两件事：
示例一：查看你的 Spring Boot 项目依赖中的 Servlet API
打开你的 Spring Boot 3.x 项目的 pom.xml（或 build.gradle），查看依赖树：
bash
# Maven 项目
mvn dependency:tree | grep servlet
# 你会看到类似这样的输出：
# jakarta.servlet:jakarta.servlet-api:jar:6.0.0:compile注意包名是 jakarta.servlet 而不是 javax.servlet。这就是 Jakarta EE 命名空间迁移在你项目中的直接体现。
示例二：对比 Java EE 8 和 Jakarta EE 10 的包名差异
Java EE 8（javax.*） |
Jakarta EE 10（jakarta.*） |
|---|---|
javax.servlet.http.HttpServlet |
jakarta.servlet.http.HttpServlet |
javax.persistence.Entity |
jakarta.persistence.Entity |
javax.transaction.Transactional |
jakarta.transaction.Transactional |
如果你在 Spring Boot 2.x 项目中看到 javax.*，而在 Spring Boot 3.x 项目中看到 jakarta.*，不要觉得奇怪------这恰恰是 JavaEE 演进为 Jakarta EE 的"历史印记"。
新手错误 vs 正确姿势
| 错误表象 | 根本原因 | 正确姿势 |
|---|---|---|
| 认为"Spring Boot 就是 JavaEE" | 混淆了"框架"与"规范"的概念 | 理解 JavaEE 是标准，Spring 是遵循标准并增强其易用性的实现者 |
| 认为"Jakarta EE 和 Java EE 完全不同" | 未理解命名空间迁移（javax→jakarta）的本质 |
本质是同一套规范换了"商标"和包名，技术内核一脉相承 |
| 认为"JavaEE 已经过时了，不需要学" | 只看到了 Spring 的易用性，忽略了 Spring 底层依赖 JavaEE 规范 | 所有 Spring 项目都依赖 Servlet、JPA、JTA 等规范------不懂规范，就无法深入理解 Spring |
疑难深度追问
Q1：为什么 Oracle 捐赠 JavaEE 时不允许开源组织使用"Java"名号？
这是 Oracle 的商标保护策略 。Oracle 拥有"Java"商标的完整所有权，如果允许 Eclipse 基金会继续使用"Java EE"这个名字，Oracle 将失去对"Java"品牌的完全控制------任何开源组织都可以随意使用"Java"命名产品，最终可能导致"Java"品牌被稀释、滥用。所以 Oracle 的立场很明确：Java 语言归我们管，但企业级规范你们可以拿走，只是不能叫 Java。
Q2：企业开发中到底用 JavaEE 规范还是 Spring 生态？
在绝大多数场景下，答案是 Spring 生态。原因有三：
- 开发效率：Spring 提供了更简洁的编程模型（注解驱动、自动配置）
- 社区活跃度：Spring 的迭代速度远快于规范本身
- 云原生适配：Spring Boot 和 Spring Cloud 对微服务、容器化部署的支持更完善
但理解规范的价值在于：当 Spring 的封装出现"黑盒"问题时（比如事务不生效、自动配置冲突），只有理解了底层规范，你才能快速定位问题。规范是"内功"，框架是"招式"------两者都重要，但内功决定了你的上限。
思考与延伸
-
列举你日常开发中用到的 3 个 JavaEE/Jakarta EE 规范（比如 Servlet、JPA、JTA），并思考：如果没有 Spring 的封装，你需要额外写多少"样板代码"？
-
检查你的项目依赖 ：打开 Spring Boot 项目的依赖树，看看有没有
javax和jakarta混用的情况。如果有，思考这可能带来什么问题。 -
延伸阅读：如果你对 Jakarta EE 的演进历史感兴趣，可以查阅 Eclipse 基金会官网的"Jakarta EE FAQ"以及"Jakarta EE 11 Release Announcement"，了解最新的规范动态。
参考与延伸阅读
- Eclipse Foundation. Jakarta EE 11 Release Announcement. Jakarta EE Official Website, 2025-06-26
- Eclipse Foundation. Jakarta EE FAQ. Jakarta EE Official Website
- Baeldung. Java EE, J2EE 与 Jakarta EE 的演变. Baeldung中文网, 2024-01-08
- InfoQ. Jakarta EE 11 Delivers One New Specification, 16 Updated Specifications and Modernized TCK. InfoQ, 2025-07-01
- Eclipse Foundation. Jakarta EE Platform Specification, Version 11.0. Jakarta EE Official Website, 2025-03-10
- 百度百科. Jakarta EE. 百度百科, 2026-03-31