Ant + WebLogic 环境下的 JDK8 → JDK17 迁移调查

Ant WebLogic 环境下的 JDK8 → JDK17 迁移调查使用 jdeps / jdeprscan 进行依赖关系分析的实践记录1. 整理调查对象本次处理的是日本业务系统中常见的以下构成Java EE 系统Ant 构建WebLogic Server 12c对应 JDK8Eclipse 开发环境无依赖管理工具不使用 Maven / Gradle注意WebLogic Server 对 JDK17 的支持需要14.1.1.0 → 14.1.2.0 以上版本。请确认现有的 WebLogic 版本必要时请考虑升级。本次工作是 JDK8 → JDK17 迁移的前期调查。首先进行的是「确定扫描对象」的整理。本系统以 EAR 格式进行分发内部包含WAREJB jar等多个模块。因此首先展开 EAR将本次的调查对象整理为以下两类classes 目录已编译的 class 文件各种 jar 文件也就是说本次的任务是以从 EAR 分解得到的 class / jar 为对象调查与 JDK17 的不兼容性。2. jdeps 与 jdeprscan 的作用在开始扫描之前先整理一下两个工具的作用。工具目的jdeps调查 jar / class 所依赖的类和模块jdeprscan检测 Deprecated / Removed API 的使用位置作业流程如下首先使用jdeps掌握依赖关系补全 classpath然后使用jdeprscan检测 JDK17 不兼容的 API3. 确定依赖关系构建 classpath在使用jdeps或jdeprscan时如果无法解析依赖的类会出现以下错误class … not found由于本项目不使用 Maven因此不存在pom.xml或 dependency tree 这样的依赖管理。在本项目中最初的 classpath 设定仅使用了服务启动时.bat文件中所记载的内容从日志中获取。然而在扫描第一个 jar 文件时便出现了上述错误。原因在于日志中记载的 classpath 仅包含 EAR 文件启动所需的依赖而当前扫描对象是 jar 文件因此需要的是 jar 文件构建时所使用的依赖。为此查阅了 Ant 的build.xml将 jar 构建时所使用的依赖补充到了 classpath 中。即便如此在后续扫描中该错误再次出现。借助jdeps的输出信息与 AI 辅助找到了最后一块拼图——散布在各个 WAR 包中的lib目录。这说明同一 EAR 包内的各模块之间存在依赖关系。将各 WAR 的lib也加入 classpath 后class not found的错误得以彻底解决。然而另一个问题随之出现。扫描结果中出现了「エラー Methodref ……を解決できません」。原因是 classpath 中存在同名但版本不同的 jar 包。由于 classpath 按从左到右的顺序进行类的检索旧版 jar 被优先引用。而应用程序实际运行时使用的是新版 jar——新版相较旧版新增了方法的重载オーバーロード。因此jdeprscan 参照旧版 jar 进行扫描时该重载方法不存在从而导致了解析失败。Ant 项目的注意事项Ant 项目中不存在 Maven 的 dependency tree因此还原 classpath 是最大的工作量。本次案例中通过整合以下内容构建了可供扫描的 classpath启动脚本中的 classpath项目内lib目录EAR 展开结果的 jar各 WAR 内的lib实行命令示例set cplib\*;modules\*;thirdparty\* set JAR扫描对象的绝对路径 set OUT日志输出目标的绝对路径 :: 依赖调查 %JAVA_17_HOME%\bin\jdeps.exe --class-path %cp% %JAR% %OUT% 214. API 扫描jdeprscanclasspath 构建完成后执行jdeprscan。set cplib\*;modules\*;thirdparty\* set JAR扫描对象的绝对路径 set OUT日志输出目标的绝对路径 :: 执行扫描必须指定 --class-path 和 --release %JAVA_17_HOME%\bin\jdeprscan.exe --class-path %cp% --release 17 %JAR% %OUT% 21注意省略--class-path选项辛苦构建的 classpath 将完全不被使用请务必明确指定。同时明确指定--release 17可以从命令中一目了然地看出正在与 JDK17 的废弃 API 列表进行对照也能防止在其他环境复用时发生误操作。通过将日志输出到文件可以在之后随时确认。扫描结果示例class com/example/app/LegacyUtil uses deprecated method java/lang/Thread::stop()V class com/example/app/DataHelper uses deprecated method java/util/Date::init(III)V class com/example/app/XmlParser uses deprecated class com/sun/org/apache/xml/internal/utils/URI注意输出中包含forRemovaltrue的项目是预计在未来版本中被删除的 API请优先处理。本次幸运的是仅存在对旧 API 的引用部分 deprecated API因此不需要大规模的依赖更新或代码修改。5. 应对大量代码修改JDK 迁移还有另一个课题那就是大量的代码修改。确认jdeprscan的结果后会在多处检测到 Deprecated API / Removed API。由于手动修改这些内容非常耗时目前正在开发一款使用 PowerShell v5.1 的辅助工具。工具的使用流程如下解析扫描结果提取修改候选将 Evidence 输出到 CSV人工审查仅自动应用已批准的修改也就是说采用AI 自动化 人工审查的形式。关于该工具的详细内容将在另一篇文章中介绍。总结对于 Ant WebLogic 这样的遗留 Java EE 系统JDK 迁移的第一道门槛就是掌握依赖关系。本次调查采取了以下步骤展开 EAR整理扫描对象从启动脚本、build.xml、EAR 展开结果、各 WAR 的lib构建 classpath使用jdeps --class-path调查、补全依赖关系使用jdeprscan --class-path --release 17检测 API 不兼容性对于不使用 Maven 的系统正确构建 classpath以及必须明确指定--class-path是非常重要的。目前正在开发使用 PowerShell 的辅助工具关于该工具也将在另一篇文章中介绍。本文转载自作者的 Zenn 主页https://zenn.dev/lockie2022