你好，欢迎来到《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），查看依赖树：
# Maven 项目mvn dependency:tree|grepservlet# 你会看到类似这样的输出：# 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
