Java平台模块系统

Java平台模块系统（Java Platform Module System，简称JPMS）指定了Java代码和相关资源的集合的分发格式。它还指定了一个用于存储这些集合，或者说模块的存储库，并确定如何发现、加载它们，以及检查它们的完整性。它包含了命名空间等功能，旨在修复已有JAR格式中的一些缺点，尤其是JAR地狱，这可能导致类路径和类加载等问题。

Java模块系统最初是在JCP下开发的，称为JSR 277，并计划与Java 7一起发布。

后来，JSR 277被搁置，并创建了Jigsaw项目来将JDK模块化。该JSR已被JSR 376（Java平台模块系统）取代。

Jigsaw项目最初打算用于Java 7（2011年），但被推迟到Java 8（2014年），作为备用计划的一部分，后再次被推迟到2017年的Java 9版本。包含了Java模块系统的Java 9于2017年9月21日发布。

 架构 

Java 9中实现的Java模块系统包括以下和JSR（Java规范请求）：

 JEP 200：模块化JDK：定义JDK的模块化结构
 JEP 201：模块化源代码：将JDK源码按模块化重新组织，增强构建系统来编译模块，并在构建时强制执行模块边界
 JEP 220：模块化运行时映像：重构JDK和JRE运行时映像，以适应模块并提高性能、安全性和可维护性
 JEP 261：模块系统：实现Java平台模块系统
 JEP 282：Java链接器：创建工具以将一组模块及其依赖项组装和优化为自定义运行时映像
 JSR 376：Java平台模块系统

此外，JDK 9还添加了其它几项功能，来轻松过渡到模块系统：

 JEP 238：多版本JAR文件：扩展JAR文件格式，以便多个特定于Java版本的类文件版本可以共存于单个存档中。
 JEP 253：为模块化准备JavaFX UI控件和CSS API：为JavaFX功能定义公共API，这些功能目前只能通过内部API获得，并将因模块化而变得无法访问。
 JEP 260：封装大多数内部API：使大多数JDK的内部API默认不可访问，但保留一些关键的、广泛使用的内部API可以访问，直到其全部或大部分功能存在受支持的替代品为止。
 JEP 275：模块化Java应用程序的打包：将针对JDK 9进行改进，以使其能够识别模块，例如可以打包一个模块及其依赖的所有模块。

 模块的属性 

模块是一种新的代码组织方式。与JAR文件相反，模块显式声明它们依赖哪些模块，以及导出哪些包。显式依赖关系声明可以更轻松地推理大型应用程序与软件组件之间的依赖关系，从而提高代码完整性。

模块声明放在module-info.java文件中，该文件位于模块源文件层次结构的根目录。在编译时和运行时，JDK都会验证模块之间的依赖关系以及交互。

例如，以下就是一个模块声明。它声明模块com.foo.bar依赖于另一个模块com.foo.baz，并导出com.foo.bar.alpha和com.foo.bar.beta两个包。

module com.foo.bar {
    requires com.foo.baz;
    exports com.foo.bar.alpha;
    exports com.foo.bar.beta;
}

com.foo.bar.alpha和com.foo.bar.beta两个包中的公有成员将可由依赖模块访问。而私有成员则无法访问，即使通过反射等手段也不行。请注意，在Java 9到Java 16中，是否允许这种“非法访问”，事实上取决于命令行设置。

JDK自身在Java 9中已经被模块化。

 与OSGi的链接 

Java模块系统并不打算支持OSGi平台当前支持的所有功能（例如生命周期模型和服务注册表）。但Java模块系统也支持某些OSGi不支持的功能，例如编译时的模块化，以及内置支持native库。2016年有几篇探讨Java模块系统和OSGi如何互操作的文章，可以在InfoQ，以及OSGi联盟博客上找到。

 参见 



 Java类加载器

 参考资料 

 外部链接 








Category:Java规范请求