jdeps生成module-info.java是模块化迁移起点，需人工校验依赖、精简exports、补全opens，并结合--module-path编译验证。
用 jdeps 自动生成 module-info.java 是模块化迁移中高效起步的关键一步，但生成结果只是起点，不能直接照搬。核心在于理解它输出的依赖逻辑，并结合项目实际做人工校验与精简。
明确 jdeps 生成 module-info 的典型命令与前提
要让 jdeps 输出可用的 module-info.java，需满足两个基本条件：目标 JAR 文件已放在模块路径上（或至少能被识别为潜在模块），且你使用了 --generate-module-info 参数。
- 分析单个第三方 JAR 并生成描述符：
jdeps --ignore-missing-deps --generate-module-info libs/ libs/core-3.4.1.jar
该命令会在libs/目录下生成module-info.java，文件名基于 JAR 名称推导（如core-3.4.1.jar→core模块名） - 若 JAR 依赖 JDK 内部 API（如
sun.misc.Unsafe），建议加--add-modules java.base或指定完整模块集，避免误报“missing” - 不推荐对含大量反射调用的旧库直接生成后就编译——
jdeps无法自动识别opens需求，必须人工补全
生成内容常见问题与变量配置建议
jdeps 输出的 module-info.java 通常只包含 requires 和基础 exports，但真实项目中需按角色区分依赖类型和导出策略：
-
requires 应分级处理：
自动生成的requires java.desktop等可保留；但若发现requires com.google.gson实际只用于测试，则应改为requires static com.google.gson，避免运行时强依赖 -
exports 不宜全开：
jdeps可能导出整个包（如exports com.example.util），但若其中含内部工具类（如com.example.util.internal.*），应拆分为exports com.example.util.api，并删掉非公共包 -
缺失 opens 必须手动添加：
使用 Spring、Hibernate 或 Jackson 的模块，只要涉及反射创建实例或序列化私有字段，就必须补opens com.example.model to com.fasterxml.jackson.databind这类声明，jdeps完全不检测此需求
结合 jdeps --module 分析跨模块调用链
当项目已有多个命名模块，想验证它们之间是否符合预期依赖关系，可用：
立即学习“Java免费学习笔记（深入）”；
-
jdeps --module-path mods/ --module com.example.app
查看com.example.app模块实际依赖哪些模块（包括传递依赖），比仅看module-info.java更真实 - 配合
--check参数快速定位断裂点：jdeps --module-path mods/ --check com.example.app,com.example.service
若某模块未在mods/中提供，会直接报错并提示缺失模块名，便于提前清理无效 requires - 对混合环境（部分 JAR 未模块化），
jdeps会将其识别为“自动模块”，名称取自 JAR 文件名（如log4j-core-2.20.0.jar→log4j.core）。此时应在requires中使用该自动名，而非猜测的 Maven 坐标
后续动作：从生成到可用的最小闭环
生成的 module-info.java 不是终点，而是模块化改造的中间产物。完成以下三步才算真正可用：
- 把生成的文件放入
src/main/java/对应位置（如src/main/java/module-info.java或子模块专属目录） - 用
javac --module-source-path src -d mods编译，观察是否报module not found或package not exported—— 这些错误比生成结果更有指导意义 - 运行前用
java --module-path mods -m com.example.app/com.example.app.Main启动，确认无IllegalAccessError；若有，大概率缺opens或requires transitive
