Java代码复用与模块化编程技巧

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Java代码复用与模块化编程详解》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

Java模块化（JPMS）是支撑大规模代码重用的基础设施，package不等于module：前者无访问控制、无依赖验证、无法封装资源；module-info.java通过requires/exports/opens显式声明依赖与可见性，exports限制public访问，opens仅允许反射访问；混用-classpath会创建隐式命名模块破坏隔离。

Java 代码重用与模块化不是两个并列概念，而是演进关系：重用是目标，模块化（尤其是 module-info.java 引入的 JPMS）是支撑大规模重用的基础设施。没有模块边界约束的“重用”，往往退化为复制粘贴或脆弱的包级耦合。

为什么 package 不等于 module

很多人把 package 当作模块用，比如建个 com.example.utils 包放一堆静态工具类。这能实现基础复用，但存在明显缺陷：

• package 无访问控制粒度——无法声明“只允许 A 模块调用本模块的某个类”，public 类对整个类路径可见
• 运行时无依赖验证——即使你删了 commons-lang3 的 jar，只要没调用其类，JVM 仍能启动，错误延迟暴露
• 无法真正封装资源——resources/ 下的配置文件、SPI 实现类默认全部对外可读可发现

而 module-info.java 显式声明 requires、exports、opens，让 JVM 在启动阶段就校验依赖完整性，并限制包的可访问范围。

exports 和 opens 的关键区别

两者都用于开放包，但语义和用途完全不同：

• exports com.example.api;：仅允许其他模块访问该包下的 public 类型及其 public 成员（编译期 + 运行期强约束）
• opens com.example.config;：允许其他模块在运行时通过反射访问该包下所有类型（包括 private 字段/方法），专为序列化、测试、框架注入等场景设计
• 若只需导出 API，绝不要用 opens 替代 exports，否则破坏封装性

module my.app {
    requires java.base;
    requires com.fasterxml.jackson.databind;
    exports com.myapp.api;        // ✅ 正常提供接口
    opens com.myapp.config;       // ✅ 允许 Jackson 反射读写 private 字段
}

模块路径（--module-path）下 classpath 的残留风险

启用模块系统后，仍混用 -cp（即 classpath）会触发隐式命名模块（unnamed module），它能读取所有其他模块的 exports，也能被所有模块读取——相当于把模块墙凿了个大洞。

• 现象：javac --module-path mods -d out Main.java 编译成功，但运行时抛 NoClassDefFoundError，因为某依赖实际来自 classpath 而非模块路径
• 验证方式：启动时加 --show-module-resolution，观察每个类加载自哪个模块
• 修复原则：所有依赖（包括自己编译的模块）必须统一走 --module-path；如需兼容传统 jar，用 jar --file=xxx.jar --describe-module 检查是否含 Automatic-Module-Name

模块化真正的难点不在写 module-info.java，而在于重构已有项目时识别隐式依赖——比如一个 Utils.class 静态方法内部调用了 javax.xml.bind，而这个包在 Java 9+ 已移出 java.base，不显式 requires 就会在运行时报错。这类问题不会在编译时报出，必须靠模块化启动验证才能暴露。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。