Java 8 迁移的账本正在翻转：为什么留守才是昂贵选项

生产环境里大约每四个 Java 代码库就有一个仍跑在 Java 8 上。这早已是行业内部的一个老梗，但梗之所以成立，是因为它确实描述了现实。一位 Java 开发者在 YouTube 视频中专门回应了这个问题：他想帮那些试图说服管理层升级的工程师，把"升级很不划算"这个假设重新算一遍。结论是——迁移的成本曲线已经变了，继续留守 Java 8 反而变成了更贵的那条路。

为什么这么多公司卡在 Java 8

模块系统与 API 移除留下的坑

Java 9 引入的模块系统强制封装了 JDK 内部结构。任何通过反射访问 sun.misc 或 com.sun 的库——Mockito、Lombok、Hibernate、Spring 代理——都会开始报错或抛出警告。同时 RT.jar 被移除，依赖扫描 classpath 的工具也随之失效。

到了 Java 11，一批存在多年的 API 被直接删除。JAXB 就是典型例子：用它将 XML 映射为对象的应用，升级到 11 后代码直接无法编译，除非手动从 Maven Central 找替代库。既然 Java 8 上一切都能跑，很多团队选择"以后再说"——然后就一直没有以后。

**JPMS（Java Platform Module System）**是 Java 9 引入的模块化基础设施，其核心是 module-info.java 描述符与 java.base 等平台模块。它不仅把 JDK 自身拆分为约 70 个模块，还通过强封装默认禁止对 sun.misc.Unsafe、java.lang.reflect 内部字段等进行深反射访问，除非显式添加 --add-opens 或 --add-exports 启动参数。这正是 Mockito、Lombok 等依赖字节码操作或反射的库在 Java 9+ 上突然报 InaccessibleObjectException 的原因。同时 RT.jar 被移除，classpath 扫描工具（如老版本 Spring 的组件扫描优化）失去了可枚举的类索引，需要改用 jrt:/ 文件系统或 ClassLoader.getSystemResources。理解 JPMS 的封装边界，是判断一次升级究竟需要改代码还是只需调 JVM 参数的关键。

升级门槛的复合效应

推迟升级带来的是滚雪球式的债务。Spring Boot 3.0 要求 Java 17，这意味着留在 Java 8 的团队同时也被困在 Spring Boot 2.7 上。而一旦决定升级，就要同时处理 JDK 破坏性变更、框架迁移，以及从 javax.* 到 jakarta.* 的全量命名空间迁移。

命名空间问题的根源在于：Oracle 将 Java EE 移交给 Eclipse 基金会时保留了商标权，Eclipse 无法修改 javax 包内的任何内容。2019 年 5 月，Eclipse 宣布谈判破裂，API 全部更名为 Jakarta。据亚马逊的估算，从 Java 8 升级到 17 平均每个应用需要 50 个开发者日——这个数字后面还会再出现。

Jakarta EE 命名空间迁移是升级路径上最容易被低估的一块硬骨头。2017 年 Oracle 将 Java EE 移交给 Eclipse 基金会，但保留了 "Java" 商标，导致 Eclipse 不能继续在新的规范版本中使用 javax.* 包名。2019 年谈判破裂后，所有 API 的包名改为 jakarta.*，并在 Jakarta EE 9 中一次性完成切换。对应用而言，这意味着源码中每一处 import javax.servlet.*、javax.persistence.*、javax.validation.* 都要改成 jakarta.*，且第三方库必须同步升级到兼容版本，否则会出现同一类被两个类加载器加载的 ClassCastException。Spring Boot 3.0 正是以 Jakarta EE 9+ 为基线，因此它是强制 Java 17 与强制 jakarta 命名空间两道门槛同时到来的节点，这也是升级工作量在 Spring Boot 3 处陡增的根本原因。

Java 8 就是死不了

Oracle 对 Java 8 的商业支持原本应在 2019 年结束，后来推到了 2030 年底。Spring Boot 2.7 的商业支持从 2025 年 2 月延到 8 月，再延到 2026 年底，现在已经是 2029 年 6 月。Oracle 路线图中甚至有一个叫"延续支持"的层级，结束日期写着"无限期"——官方明确表示，支持期限取决于客户采用情况。留在 8 上的公司越多，对 8 的支持就越长。

留守的真实代价

性能与成本：来自 Netflix 的数据

Netflix 在 2023 年公开承认，年初时他们大部分服务还跑在 Java 8 上。这家全球最大的 Java 用户之一尚且如此，说明卡在旧版本绝非单纯的懒惰或吝啬。

他们从 Java 8 迁移到 17 的案例研究提供了关键数据：在没有任何代码改动的情况下，同样的服务 CPU 占用降低了约 20%，仅仅因为 G1 垃圾回收器的改进。Netflix 的 Paul Baker 在 QCon 上被问到如何说服管理层买单时回答："这个数字是真实的。"在 Netflix 的规模上，20% 的 CPU 节省意味着可观的成本削减。

这说明说服管理层的路径其实很清晰：找到一个能省钱的数字。而这还只是 Java 8 到 17 的差距。Java 25 LTS 引入的紧凑对象头在特定负载下可减少 22% 堆内存和 8% CPU，且只需调整一个 JVM 标志。

G1 垃圾回收器自 Java 7 引入、Java 9 起成为默认 GC，但它在 Java 8 中还只是实验性选项，默认仍是 Parallel GC。Java 8 到 17 之间，G1 经历了大量针对停顿预测、并发标记周期和 region 回收效率的改进，Netflix 观察到的约 20% CPU 下降，主要来自这些改进减少的 GC 线程开销与更少的 full GC。此外，**紧凑对象头（Compact Object Headers，JEP 450）**在 Java 25 中正式成为产品特性，它把每个对象的对象头从 96 位压缩到 64 位，在对象密集的负载下可节省约 22% 堆内存并降低约 8% CPU，且只需开启 -XX:+UseCompactObjectHeaders。这两个数据点说明，JDK 版本带来的性能收益往往不需要改动业务代码，是说服管理层时最直接的论据。

补丁费用与生态脱节

性能收益在大规模场景下才明显，但有一项成本对所有团队几乎同等适用：Java 8 生态中的 Spring Boot 2.7 和 Spring Framework 5.3 已脱离免费支持期，安全补丁需要付费获取。

更麻烦的是生态正在主动脱钩。Kafka 4.0 和 JUnit 6 都已要求 Java 17，后者的理由是"我们依赖的重要项目可能会比我们更早放弃 Java 8"。这意味着留在旧版本上的团队会发现越来越多的工具链无法使用。

AI 工具如何改写迁移的经济账

这个议题在最近一年出现了实质性变化。OpenRewrite 为每一跳升级（8→11→17→21→25）以及 Spring Boot 2→3 都提供了复合配方：自动补回 JAXB 和 JAXWS 依赖、用受支持 API 替换 JDK 内部调用、将整个代码库中的 javax 重写为 jakarta。只需添加 Maven 或 Gradle 插件，运行后得到一份可审查的 diff。

真正的新变量是 AI 工具开始包裹这些配方。配方生成 diff 后，代理自动执行构建、读取报错、修复问题，循环直到构建通过。GitHub 的 Java 现代化代理和 Amazon Q 都提供此类能力。对亚马逊而言，此前每个应用 50 开发者日的迁移，内部使用 AI 工具后缩短到几个小时。

需要留意的是，GitHub 和亚马逊公布的数据同时也服务于它们销售工具的目的，因此很可能展示的是最佳情况。Netflix 则不同——他们不卖开发工具，却用 Claude Code 以无头批处理模式将 3000 到 4000 个服务从 Spring Boot 3 迁移到 Spring Boot 4。Paul Baker 表示，代理的表现超过了他们的确定性工具。

OpenRewrite 是一个基于源码 AST 的自动化重构框架，它把升级知识编码为可组合的"配方（recipe）"，例如 UpgradeToJava17 会串联处理 JDK 内部 API 替换、依赖版本更新和语法调整，SpringBoot2To3 则额外完成 javax 到 jakarta 的重写。配方运行后输出的是标准 diff，可以走代码审查流程，因此不会绕过团队的治理。新的变化在于代理式循环（agentic loop）：AI 工具在配方产生 diff 之后，自动触发构建、解析编译或测试报错、再生成修复补丁，如此往复直到通过。GitHub 的 Java 现代化代理和 Amazon Q 都采用这一模式。需要区分的是，OpenRewrite 负责确定性的机械改写，AI 代理负责处理配方无法预知的残留问题，二者是互补而非替代关系。

怎样的说服逻辑现在能成立

几年前管理层说"不"时，他们看到的是类似"50 个专职开发者日、所有其他工作暂停"的估算，回报却是要在大规模下才显现的性能提升。拒绝是合理的。

现在的账本需要重算。成本侧：同样的迁移可能只需几小时到几周，且大部分时间由代理在后台运行，开发者只需在检查点介入，新功能开发不必全面停摆。收益侧：可观的性能提升、不再为安全补丁额外付费、工具链兼容性得以维持、不必再追踪那些可能继续被推迟的生命周期截止日期。

当然，也有真实的例外情况。有人在月服务 4000 万用户的电信系统上运行 Spring 2.7 和 Java 11，迁移的风险评估完全不同；有团队的 WebSphere 版本限制了他们能用的 JDK；还有荷兰某市政厅的应用运行在外部承包商维护的服务器上，既无升级意愿，城市也没有预算施压。

Java 冠军 Johan Vos 有一句话概括了这种权衡：迁移到新版本有一笔小但立即的成本；留在旧版本则有一笔巨大、灾难性但不立即的成本。在 AI 辅助迁移工具成熟的当下，这笔延迟账单的利息，已经明显高于提前还款的手续费。对于那些考虑行动，目标版本建议直接跳到 21 或 25——17 的免费支持已经结束，没有必要在那里停留。