1. 概述
本文将深入探讨 Jakarta EE 为何成为 Java EE 的继任者，并手把手教你完成迁移实战。无论你正在维护遗留系统还是升级框架，都能找到实用解决方案。
2. Jakarta EE 的诞生始末
Java EE（Java Platform, Enterprise Edition）最初由 Sun Microsystems 于 1999 年推出，旨在为 Java 语言提供企业级扩展能力。2009 年 Oracle 收购 Sun 后，2017 年决定将 Java EE 交由 Eclipse 基金会（以孵化开源项目闻名的非营利组织）主导开发。由于 Oracle 保留 Java 商标权，社区投票后项目正式更名为 Jakarta EE。
3. 为何必须迁移到 Jakarta EE？
首要原因：原 Java EE 技术栈已停止更新，不再获得任何新特性或改进。在技术日新月异的今天，Jakarta EE 能让我们拥抱新开发范式，例如：
- ✅ 更完善的微服务支持
- ✅ 云原生应用开发能力
其次，迁移能获得长期技术支持。主流厂商和应用服务器（如 WildFly、Payara）已全面转向 Jakarta EE 生态。
最后，框架升级可能强制要求迁移。比如使用 Spring 开发的 Web 应用，升级到 Spring Boot 3 时就必须完成 Jakarta EE 迁移。
4. Java EE 到 Jakarta EE 迁移实战
迁移分三步走：先改造应用代码，再处理外部依赖，最后确保运行环境兼容。
4.1. 应用代码改造
表面看只需将 javax 包名替换为 jakarta，涉及：
- 类导入语句
- pom.xml 依赖声明
- 配置文件（如 web.xml）
⚠️ 实际比全局替换更复杂：部分 javax 包未纳入 Jakarta EE（完整列表见 Jakarta EE GitHub）。
推荐自动化方案：
- IntelliJ IDEA 用户：打开
Refactor>Migrate Packages and Classes> 选择 Java EE to Jakarta EE > 点击Run自动更新所有导入 - OpenRewrite 工具：通过其 Jakarta EE 迁移配方 实现代码重构
- Eclipse Transformer：专为解决此类迁移设计，支持命令行或 Maven 集成
4.2. 外部依赖处理
好消息：主流开源库（如 Hibernate、Jersey）已完成 Jakarta EE 迁移，只需升级版本即可。注意：
- 部分库升级了大版本号（如 Hibernate 5→6）
- 部分迁移了仓库坐标（如
javax.persistence→jakarta.persistence）
❌ 踩坑预警：当遇到未迁移的依赖时：
- 评估是否替换为更现代的替代方案
- 若必须保留，可用 Eclipse Transformer 或 OpenRewrite 动态修改字节码（示例命令）：
# 使用 Eclipse Transformer 转换未迁移的 JAR java -jar transformer.jar -i legacy-lib.jar -o migrated-lib.jar - Tomcat 用户可尝试 Apache 官方迁移工具
⚠️ 重要提醒：同一应用中混用 jakarta 和 javax 依赖会导致命名空间冲突，务必避免！
4.3. 运行环境适配
应用服务器（如 TomEE、GlassFish）自带 Java EE 库（通常在 pom 中标记为 provided）。迁移时需：
- 检查服务器是否支持 Jakarta EE
- 升级到兼容版本（参考 Jakarta EE 官方兼容列表）
推荐服务器版本对照表： | 服务器 | 最低兼容版本 | |--------------|--------------| | WildFly | 27+ | | Payara | 6+ | | Tomcat | 10+ | | OpenLiberty | 22.0.0.12+ |
5. 总结
本文揭示了 Oracle 将 Java EE 移交 Eclipse 基金会后，项目更名为 Jakarta EE 的历史背景。迁移不仅是技术升级的需要，更是保持应用生命力的关键。虽然迁移过程比想象中复杂，但通过 IntelliJ IDEA、OpenRewrite 等工具可大幅简化操作。
对于遗留依赖，我们既可以通过工具动态转换字节码，也可将其作为构建流程的一环（如在 Maven 中集成 Transformer）。只要遵循「先代码、后依赖、再环境」的迁移路径，就能平滑过渡到 Jakarta EE 生态。