本文详解如何解决gradle 8.1 + java 17环境下因module-info.java引用非命名模块（如rengine、rserve）导致的“module not found”编译错误，重点涵盖模块路径推断失效、第三方库模块化缺失及正确插件配置。
本文详解如何解决gradle 8.1 + java 17环境下因module-info.java引用非命名模块（如rengine、rserve）导致的“module not found”编译错误，重点涵盖模块路径推断失效、第三方库模块化缺失及正确插件配置。
在将Maven项目迁移至Gradle构建体系时，尤其当项目启用Java模块系统（JPMS）后，一个常见但易被忽视的问题是：module-info.java中声明的requires语句无法解析传统JAR包依赖。你遇到的错误：
error: module not found: REngine
requires REngine;
^
error: module not found: Rserve
requires Rserve;根本原因并非代码或路径错误，而是Gradle默认不具备对非命名模块（non-modular JARs） 的自动模块名映射与模块路径（--module-path）自动组装能力——而Maven的maven-compiler-plugin在<modules>模式下会隐式处理此逻辑。
? 根本原因分析
- REngine:2.1.0 和 Rserve:1.8.1 是典型的自动模块（Automatic Modules）：它们不含module-info.class，但Gradle需将其视为模块并赋予规范模块名（如org.rosuda.rengine），才能满足requires REngine的解析需求。
- 你启用了 java { modularity.inferModulePath.set(true) }，该设置仅启用模块路径推断，但不提供自动模块名标准化或模块路径构建支持——它依赖于Gradle原生能力，而Gradle 8.1对此支持有限。
- org.javamodularity.moduleplugin（即 gradle-modules-plugin）正是为此而生：它为Gradle补全JPMS关键能力，包括：
- 自动为传统JAR生成合规模块名（如org.rosuda.rengine → REngine）；
- 将implementation依赖自动注入--module-path而非--class-path；
- 支持requires static、requires transitive等高级模块语法；
- 与JUnit 5、TestNG等测试框架无缝集成。
✅ 正确修复步骤
1. 添加模块化专用插件（关键！）
在 rengine-rserve-wrapper/build.gradle.kts 的 plugins 块中，必须显式引入 org.javamodularity.moduleplugin：
plugins {
id("java-library")
id("org.javamodularity.moduleplugin") version "1.8.12" // ✅ 必须添加
}⚠️ 注意：该插件版本 1.8.12 兼容 Gradle 8.1 + Java 17，且已通过 Maven Central 验证。避免使用过旧（如 <1.8.0）或过新（如 2.x，尚不兼容Gradle 8.1）版本。
立即学习“Java免费学习笔记（深入）”；
2. 修正 module-info.java 中的模块名
自动模块名由JAR的groupId和artifactId按规则生成（小写+点号转连字符）。根据 JPMS规范，org.rosuda.REngine:REngine:2.1.0 的标准自动模块名为 org.rosuda.rengine（非 REngine）：
module data.mining.apps.rengine.rserve.wrapper.main {
requires org.mongodb.bson;
requires org.rosuda.rengine; // ✅ 改为标准自动模块名
requires org.rosuda.rserve; // ✅ 同理，Rserve → org.rosuda.rserve
}? 提示：可通过 jar -f ~/.gradle/caches/modules-2/files-2.1/org.rosuda.REngine/REngine/2.1.0/.../REngine-2.1.0.jar | grep module-info 验证JAR内无module-info.class，确认其为自动模块。
3. （可选）显式配置模块路径行为
若仍遇问题，可在 build.gradle.kts 中增强控制：
java {
modularity.inferModulePath.set(true)
}
// 确保插件接管模块路径构建
tasks.withType<JavaCompile> {
options.compilerArgs.addAll(
"--module-path", classpath.asPath,
"--add-modules", "ALL-SYSTEM,org.rosuda.rengine,org.rosuda.rserve"
)
}但通常 moduleplugin 已自动处理，无需手动干预。
4. 清理并重建
执行以下命令清除缓存并强制重编译：
./gradlew clean build --refresh-dependencies
? 关键注意事项
- 不要删除 modularity.inferModulePath.set(true)：它与 moduleplugin 协同工作，前者启用模块感知，后者提供实现。
- 避免混合使用 Maven 和 Gradle 模块配置：Maven 的 maven-compiler-plugin 行为不可直接迁移到Gradle，必须用Gradle生态对应方案。
- 检查依赖传递性：若 REngine 或 Rserve 依赖其他非模块化库（如 commons-math3），它们也会成为自动模块，需在 module-info.java 中一并声明 requires。
- IDE同步：IntelliJ IDEA 或 VS Code 需重新导入Gradle项目（右键 → Reload project），否则模块解析可能仍失败。
✅ 最终验证效果
成功配置后，gradle compileJava 将：
- 自动将 REngine-2.1.0.jar 映射为模块 org.rosuda.rengine；
- 将 Rserve-1.8.1.jar 映射为模块 org.rosuda.rserve；
- 在编译期正确解析 requires 语句；
- 生成包含完整模块依赖图的 module-info.class。
? 总结：Java模块化在Gradle中不是开箱即用的功能，而是需要专用插件赋能。org.javamodularity.moduleplugin 是当前Gradle生态中解决传统库模块化接入问题的事实标准方案——它填补了Gradle原生能力与JPMS实践之间的关键鸿沟。
