Java模块化核心目标是什么？

大家好，我们又见面了啊~本文《Java模块化核心目标是什么？》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

Java模块化系统（JPMS）的核心目标是实现强封装和显式依赖，通过module-info.java在编译期确立“我用谁、我给谁用、我允许谁碰我内部”的契约，解决classpath的盲搜缺陷；exports用于编译期和运行期开放API，opens仅限运行期反射访问；自动模块虽可临时兼容非模块化库，但破坏封装且不稳定，应推动升级或打补丁。

Java模块化系统（JPMS）的核心目标是实现强封装和显式依赖——不是为了“拆代码”，而是让每个模块清楚地回答三个问题：我用谁？我给谁用？我允许谁在运行时碰我内部？

为什么必须用 module-info.java 声明依赖，而不是继续靠 classpath？

类路径（classpath）本质是“盲搜”：JVM把所有 JAR 扫一遍，直到找到某个类。这导致：

• 运行时才暴露 NoClassDefFoundError 或 IllegalAccessError，编译期完全不报错
• 任意模块都能反射访问任意类（比如 sun.misc.Unsafe），破坏设计边界
• 无法判断哪些 JAR 真正被用到，打包臃肿、启动慢、jlink 无法定制最小 JRE

module-info.java 把这些模糊关系变成编译期契约。例如：requires java.sql; 表示“我明确需要 JDBC API”，而不仅是“我碰巧用了 Connection 类”。

exports 和 opens 的区别到底在哪？

这是最常混淆的两个指令，关键看访问时机和方式：

• exports com.example.api;：编译期 + 运行期都开放——其他模块能正常 import、new、调用方法
• opens com.example.model;：仅运行期开放——只允许反射访问（如 Spring 创建实体类实例、Hibernate 绑定字段），编译期仍不可见

如果框架报 InaccessibleObjectException，优先加 opens；如果业务类要被其他模块直接使用，才用 exports。滥用 exports 等于把内部包全暴露，强封装就失效了。

第三方库没模块化怎么办？自动模块（Automatic Module）是救星还是陷阱？

把未声明 module-info.java 的 JAR 放进模块路径（--module-path），JVM 会把它转为“自动模块”，名字通常来自 JAR 文件名（如 guava-32.1.3-jre.jar → 模块名 guava）。

• ✅ 优点：能被 requires 引用，模块图可构建
• ❌ 缺点：它自动导出所有包，等于没有封装；且名字不稳定（改 JAR 名就失效）；无法使用 transitive 或 uses/provides

实践中建议：--add-modules 临时启用，但长期应推动升级或用 moditect 插件打补丁，别把它当正式模块对待。

模块化最难的从来不是写 module-info.java，而是识别哪些包该导出、哪些该开放、哪些该彻底隐藏——这要求你真正理解代码的职责边界，而不是机械地把旧项目目录一拆了之。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~