为什么是Jigsaw / JPMS项目？

Question

在我看来，Java的包管理系统总是简单有效的。它被JDK本身大量使用。我们一直在使用它来模仿名称空间和模块的概念。

项目Jigsaw (又名Java平台模块系统)试图填补的是什么？

从官方网站：

本项目的目标是为Java SE平台设计和实现一个标准模块系统，并将该系统应用于平台本身和JDK。

Answer 1

拼图和OSGi正试图解决同样的问题:如何允许更粗粒度的模块交互，同时屏蔽它们的内部。

在Jigsaw的例子中，更粗粒度的模块包括Java类、包及其依赖项。

这里有一个例子: Spring和Hibernate。两者都依赖于第三方JAR CGLIB，但它们使用不同的、不兼容的JAR版本。如果您依赖标准JDK，您可以做什么？包括Spring希望中断Hibernate和visa相反的版本。

但是，如果您有一个更高级别的模型，比如Jigsaw，您可以很容易地在不同的模块中管理不同版本的JAR。把它们当成更高级的包。

如果您构建了来自GitHub源的Spring，您也会看到它。他们已经重做了框架，因此它由几个模块组成:核心、持久性等等。您可以选择和选择应用程序所需的最小模块依赖集，而忽略其他模块依赖项。它过去是一个Spring，其中包含所有的.class文件。

更新:五年后，Jigsaw可能还有一些问题需要解决。

Answer 2

AFAIK的计划是使JRE更加模块化。例如，拥有更小的jars，这是可选的，并且/或您只可以下载/升级所需的功能。

它使它不那么臃肿，让你可以选择放弃可能大多数人不使用的遗留模块。

Answer 3

在马克·莱因霍尔德的在比利时Devoxx的主旨演讲基础上，Jigsaw项目将解决两个主要的问题：

1. 克拉斯帕特
2. 块状整体JDK

克拉斯帕斯怎么了？

​

我们都知道盖尔地狱的事。这个术语描述了类加载过程最终无法工作的各种方式。已知的类路径的限制是：

• 很难说是否有冲突。像maven这样的构建工具可以很好地基于工件名称完成工作，但是如果工件本身有不同的名称但内容相同，则可能会发生冲突。
• jar文件的根本问题是它们不是组件。它们只是一堆将线性搜索的文件容器。Classpath是一种查找类的方法，不管它们在哪些组件中、它们在哪些包中或它们的预期用途如何。

块状整体JDK

​

JDK的大单块性导致了以下几个问题：

• 它不适合小型设备。尽管小型IoT类型设备拥有能够运行SE类VM的处理器，但它们不一定有足够的内存来容纳所有JDK，特别是当应用程序只使用其中的一小部分时。
• 这甚至是云中的一个问题。云的目的是优化硬件的使用，如果您有数千张包含整个JDK的映像，但应用程序只使用其中的一小部分，那将是一种浪费。

模块:共同解决方案

​

为了解决上述问题，我们将模块作为一种基本的新型Java程序组件来处理。模块是一个命名的、自描述的代码和数据集合.它的代码被组织成一组包含类型的包，即Java类和接口；它的数据包括资源和其他类型的静态信息。

为了控制它的代码如何引用其他模块中的类型，一个模块声明它需要哪些其他模块才能编译和运行。为了控制其他模块中的代码如何引用其包中的类型，模块将声明它导出的包中的哪一个。

模块系统定位所需的模块，并与类路径机制不同，确保模块中的代码只能引用它所依赖的模块中的类型。Java语言和Java虚拟机的访问控制机制阻止代码访问未由定义模块导出的包中的类型。

除了更可靠之外，模块化还可以提高性能。当模块中的代码引用包中的类型时，则保证在该模块中或在该模块读取的某个模块中定义该包。因此，在寻找特定类型的定义时，不需要在多个模块中搜索它，或者更糟的是，沿着整个类路径搜索它。

依偎着

​

拼图是一个巨大的项目，正在进行了相当多年。它有一个令人印象深刻的JEPs，这是一个伟大的地方，以获得更多的信息，该项目。其中一些情况如下：

• JEP 200:模块化JDK：使用Java平台模块系统(JPMS)模块化JDK
• JEP 201:模块化源代码：将JDK源代码重组为模块，增强构建系统以编译模块，并在构建时强制执行模块边界。
• JEP 261:模块系统：实现JSR 376指定的Java平台模块系统，以及相关的JDK特定更改和增强。
• JEP 220:模块化运行时映像：重组JDK和JRE运行时映像以适应模块并提高性能、安全性和可维护性。
• JEP 260:封装大多数内部API：默认情况下使JDK的大部分内部APIs不可访问，但保留一些关键的、广泛使用的内部APIs可访问性，直到它们的全部或大部分功能存在受支持的替换为止。
• JEP 282: jlink: Java链接器：创建一个工具，该工具可以将一组模块及其依赖项组装和优化为自定义的运行时映像，如http://openjdk.java.net/jeps/220中定义的那样。

闭幕词

​

在模块系统的状态报告的初始版中，Mark描述了模块系统的具体目标如下：

• 可靠配置，将易碎的、容易出错的类路径机制替换为程序组件相互声明显式依赖的方法，以及
• 强封装，允许组件声明哪些公共类型可供其他组件访问，哪些不能访问。

这些特性将直接和间接地使应用程序开发人员、库开发人员和Java SE平台本身的实现者受益，因为它们将支持可伸缩的平台、更好的平台完整性和更好的性能。