你好欢迎来到《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 中剥离出来形成一个独立的平台——这就是J2EEJava 2 Platform, Enterprise Edition的诞生。你可以这样理解JDK 是“基础工具箱”里面有扳手、螺丝刀J2EE 是“建筑工程规范”告诉你盖一栋楼应该用什么标准、什么材料。J2EE 1.2 于 1999 年 12 月正式发布由 WebLogic 和 iPlanet后来的 Sun ONE等应用服务器率先实现。从此企业级 Java 开发有了第一套“官方标准”。二、J2EE → Java EE → Jakarta EE三次更名背后的故事这个名称演变过程很多开发者搞不清楚。我们来逐一拆解。第一次更名J2EE → Java EE2006 年2006 年随着 Java 5 的发布Sun 公司做了一次品牌梳理。“J2EE”这个名字中的“2”代表的是 Java 2 平台但 Java 5 发布后“Java 2”这个说法已经被淘汰了。于是J2EE 被更名为Java EEJava Platform, Enterprise Edition。这次更名只是品牌层面的调整技术内核没有本质变化。第二次更名Java EE → Jakarta EE2017—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到jakartaJakarta 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 11Web 层Jakarta Servlet处理 HTTP 请求/响应6.1Jakarta Server Pages (JSP)动态生成 HTML 页面3.1Jakarta Expression Language (EL)JSP/JSF 中的表达式语言5.0Jakarta WebSocketWebSocket 通信2.2业务层Jakarta Enterprise Beans (EJB)分布式业务组件重量级4.0Jakarta Contexts Dependency Injection (CDI)依赖注入轻量级4.1Jakarta Transactions (JTA)分布式事务管理2.0Jakarta Concurrency并发工具3.1数据层Jakarta Persistence (JPA)ORM 规范Hibernate 是实现3.2Jakarta Data简化数据访问Jakarta EE 11 新增1.0Jakarta Bean Validation数据校验Hibernate Validator 是实现3.1其他Jakarta RESTful Web ServicesREST APIJAX-RS 的继任者3.2Jakarta JSON ProcessingJSON 解析与生成2.1Jakarta Security安全认证与授权3.0Jakarta 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 JohnsonSpring 的创始人在 2003 年出版了《Expert One-on-One J2EE Development without EJB》一书提出了一个观点企业级开发可以更简单。他随后创建了 Spring 框架。Spring 的核心思路是拥抱 JavaEE 规范但不被规范绑架——Spring 集成了 Servlet、JPA、JTA 等规范但提供了更简洁的 API用 IoC 容器管理对象替代 EJB 的复杂生命周期管理用 AOP 实现声明式事务替代 EJB 的容器管理事务CMT用 POJOPlain Old Java Object编程替代 EJB 对特定接口的继承要求你可以这样理解两者的关系维度JavaEE/Jakarta EESpring本质一套规范接口定义一个框架具体实现 扩展谁制定的Eclipse 基金会原 Sun/OraclePivotal/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 8javax.*Jakarta EE 10jakarta.*javax.servlet.http.HttpServletjakarta.servlet.http.HttpServletjavax.persistence.Entityjakarta.persistence.Entityjavax.transaction.Transactionaljakarta.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-26Eclipse Foundation.Jakarta EE FAQ. Jakarta EE Official WebsiteBaeldung.Java EE, J2EE 与 Jakarta EE 的演变. Baeldung中文网, 2024-01-08InfoQ.Jakarta EE 11 Delivers One New Specification, 16 Updated Specifications and Modernized TCK. InfoQ, 2025-07-01Eclipse Foundation.Jakarta EE Platform Specification, Version 11.0. Jakarta EE Official Website, 2025-03-10百度百科.Jakarta EE. 百度百科, 2026-03-31