将Java 8代码自动升级至Java 17，涵盖语法转换、A…

# Java 8 → Java 17 升级方案（300个文件的电商订单系统）

一、升级前准备

• 版本选择：确认构建工具版本，Maven 建议 3.6.3+，Gradle 建议 7.3+（Gradle 7 才完整支持 Java 17）
• 依赖检查：用 mvn dependency:tree 或 gradle dependencies 梳理全部依赖，重点关注 Spring、MyBatis、日志框架等，需升级到支持 JDK 17 的版本区间（如 Spring 5.3.x+，建议直接上 Spring Boot 2.7+ 或 3.x）
• 建立基线：升级前跑通全部单元测试和核心流程回归，记录为基线

二、javax.* 替换策略

• javax.annotation：@Resource、@PostConstruct 等改用 jakarta.annotation（引入 jakarta.annotation-api 依赖）
• javax.servlet：如涉及 Web 层，Spring Boot 3 需迁移到 jakarta.servlet；若停留在 Spring Boot 2.7（Java 17 可运行），可暂保留 javax.servlet
• javax.persistence / javax.validation：分别迁移到 jakarta.persistence、jakarta.validation
• JAXB/JAX-WS（java.xml.ws 等）：Java 11 已移除，需显式引入 jakarta.xml.bind 等依赖
• 批量替换技巧：用 IDE 的 Replace in Path 或 OpenRewrite 的 org.openrewrite.java.Java17 + Jakarta recipe 自动化处理，300 个文件手工改不现实

三、Sun 内部 API 处理

• sun.misc.BASE64Encoder/Decoder → 替换为 java.util.Base64
• sun.misc.Unsafe → 视用途改用 VarHandle 或 MethodHandles
• sun.misc.Signal 等 → 寻找标准库等价物或第三方替代
• 检测手段：编译时加 --illegal-access=deny（17 默认拒绝），或使用 jdeps 工具扫描：jdeps --jdk-internals 你的jar包，会列出所有内部 API 引用及官方建议替代方案

四、编译与运行问题

• 移除过时的 -XX 参数（如 PermSize 相关，元空间已替代永久代）
• 强反射场景（老版本 cglib、反射调用 JDK 内部类）需添加 --add-opens、--add-exports 参数过渡，最终目标还是改代码去掉依赖
• 默认 GC 已是 G1，可借此做性能验证

五、推荐落地路径

1. 用 OpenRewrite（或 IntelliJ 的迁移助手）做一次性自动化重构，处理大部分机械修改

2. jdeps 扫描残留的 JDK 内部 API，逐个手工处理

3. 升级依赖版本，解决编译报错

4. 全量测试 + 灰度发布，重点回归订单创建、支付回调、库存扣减等核心链路

5. 上线后观察 GC 日志与性能指标

建议节奏：先在 CI 环境完成编译级升级，再分模块回归，预计机械替换用工具 1-2 天可完成，依赖升级和回归测试视测试覆盖度另行评估。