本文旨在讲解如何利用Java模块系统（JPMS）对Java库进行内部类封装，以防止库的使用者直接访问和实例化内部类。文章将深入探讨模块化的原理，以及如何在实际项目中应用模块化来实现API的隔离和封装。同时，也会讨论在兼容性方面的考虑，并提供一些在无法强制模块化的情况下，如何引导用户正确使用库的建议。
Java模块系统（JPMS）是Java 9引入的一个重要特性，它旨在增强Java平台的模块化能力。其中一个关键目标就是实现强封装，允许模块声明哪些公共类型可以被其他模块访问，哪些则不公开。这对于库的开发者来说至关重要，因为他们可以使用模块系统来明确定义库的公共API，并隐藏内部实现细节，防止用户直接依赖内部类。
模块声明与API导出
要使用模块系统进行封装，首先需要创建一个模块声明文件module-info.java。该文件位于模块的根目录下，用于定义模块的名称、依赖关系以及导出的包。
例如，假设我们有一个名为some.library的库，其中包含some.library.api和some.library.internal两个包，分别用于存放公共API和内部实现。我们可以创建如下的module-info.java文件：
立即学习“Java免费学习笔记（深入）”；
module some.library {
exports some.library.api;
requires etc1; // 依赖的其他模块
}在这个声明中，exports some.library.api;语句表示将some.library.api包中的所有公共类型导出到其他模块。而some.library.internal包则没有被导出，因此其他模块无法直接访问其中的类型。requires etc1;表示该模块依赖于另一个名为etc1的模块。
模块路径与类路径的区别
Java模块系统引入了模块路径（module path）的概念，它与传统的类路径（class path）有所不同。模块路径上的模块会强制执行封装规则，即只有导出的包中的公共类型才能被其他模块访问。而类路径上的类则位于一个“未命名模块”中，可以访问所有其他模块的任何包，包括未导出的包。
为了实现强封装，我们需要确保库的使用者将我们的库放在模块路径上，而不是类路径上。这可以通过在编译和运行时使用-modulepath或-p选项来实现。
兼容性与折衷
虽然模块系统提供了强大的封装能力，但它也带来了一些兼容性问题。如果库的使用者没有使用模块系统，而是将库放在类路径上，那么他们仍然可以访问库的内部类。
为了解决这个问题，我们可以采取一些折衷方案：
明确命名内部包： 如上例所示，使用.internal后缀来明确标识内部包，提醒用户不要直接依赖这些包中的类型。
使用注解： 在公共API类上使用@PublicApi等注解，在内部类上使用@InternalApi等注解，以更清晰地表明类型的用途。
语义化版本控制： 对公共API进行严格的语义化版本控制（Semantic Versioning），并明确告知用户内部API可能会频繁更改，鼓励他们避免依赖内部API。
总结与注意事项
Java模块系统为库的开发者提供了一种强大的工具，可以实现内部类的封装，提高代码的可维护性和可扩展性。然而，模块化是一个渐进的过程，需要考虑兼容性问题，并采取一些折衷方案来引导用户正确使用库。
注意事项：
- 确保库的使用者将库放在模块路径上，而不是类路径上。
- 明确命名内部包，并使用注解来标识公共API和内部API。
- 对公共API进行严格的语义化版本控制。
- 考虑使用代码分析工具来检测对内部API的依赖。
通过合理地使用Java模块系统，我们可以构建更加健壮、易于维护的Java库，并为用户提供更好的开发体验。
