使用Java 8编译的项目能否在Java 17上运行？现有迁移方案是否合理？

JDK 9 API「移除」的定义 #

JDK对API的生命周期管理有明确规则：

• 首先会给要淘汰的API加@Deprecated注解，仅标记为弃用的API仍会保留在JDK中，可以正常调用，编译时会弹出警告
• 部分确定要删除的API会额外加@Deprecated(forRemoval = true)属性，经过2~3个大版本迭代后才会被完全从JDK发行包中删除
  你看到的JDK 9中被移除的API，属于已经完成淘汰流程、正式删除的范畴，不是仅标记弃用，代码中如果直接调用这类API，在JDK 9+环境运行会直接抛出NoClassDefFoundError、NoSuchMethodError之类的错误。

JDK 8编译的项目能否在JDK 17无异常运行 #

没有统一答案，取决于项目实际依赖的API：

• 如果项目仅使用JDK 8的标准公开API，没有依赖后续版本删除的接口、没有反射调用JDK内部非标准API，大部分场景可以正常运行
• 如果项目本身或依赖的中间件用到了已删除的API、或者违反了JDK 9+模块化（JPMS）的访问规则，就会抛出异常。你遇到的Tomcat适配问题，就是低版本Tomcat调用了JDK内部受限API，被模块化的权限规则拦截导致的。

当前迁移方向的合理性 #

你采用的「JDK 8编译、JDK 17运行，逐步替换废弃API完成兼容」的方案是行业通用的稳妥迁移路径，方向是正确的，优势是风险可控，不需要一次性完成全量代码改造，可以边迭代边修复兼容问题。

可补充的迁移优化方案 #

• 先升级中间件版本：将Tomcat升级到9.0.x最新稳定版或10.1.x版本，这两个版本已经完全适配JDK 17和模块化规则，先解决基础运行环境的兼容问题
• 初期添加运行时兼容参数：对暂时来不及修改的内部API调用，可以通过--add-exports、--add-opens启动参数临时开放JDK模块访问权限，先保证业务正常运行，后续再逐步替换
• 条件允许可以加过渡版本：如果项目兼容问题较多，可以先升到JDK 11（LTS版本）作为过渡，JDK 11移除的API比JDK 17少，适配成本更低，完成全量API替换后再升级到JDK 17
• 提前扫描兼容风险：用JDK自带的jdeps工具扫描项目的依赖包，可以提前检测到已废弃、已移除的API调用，提前修复减少线上故障

内容的提问来源于stack exchange，提问作者Sai Kumar