为什么选择Jigsaw项目/JPMS？

Question

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

Jigsaw项目（又名Java平台模块系统）试图填写什么内容？

从官方网站：

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

Answer 1

根据Mark Reinhold在Devoxx比利时的主题演讲，Project Jigsee将解决两个主要痛点：

1. 类路径
2. 大规模单片JDK

我们都知道罐子地狱。这个术语描述了类加载过程最终可能无法工作的各种方式。类路径最著名的限制是：

• 很难说是否有冲突。像maven这样的构建工具可以在工件名称的基础上做得很好，但是如果工件本身有不同的名称但内容相同，则可能会发生冲突

JDK的巨大整体性导致了几个问题：

• 它不适合小型设备。尽管小型物联网类型的设备具有能够运行SE类VM的处理器，但它们不一定具有容纳所有JDK的内存，尤其是当应用程序仅使用其中的一小部分时
• 这甚至是云中的一个问题。云就是要优化硬件的使用，如果你有数千个包含整个JDK的图像，但应用程序只使用其中的一小部分，那将是一种浪费

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

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

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

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

Jigsaw是一个巨大的项目，已经持续了好几年了。它有大量的JEP，这是获取更多项目信息的好地方。其中一些JEP如下所示：

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

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

• 可靠的配置，用一种程序组件声明彼此之间显式依赖的方法，以及

这些特性将直接或间接地使Java SE平台本身的应用程序开发人员、库开发人员和实现人员受益，因为它们将实现可扩展的平台、更大的平台完整性和改进的性能。

Answer 2

AFAIK该计划是使JRE更加模块化。即有较小的可选罐子和/或您可以仅下载/升级您需要的功能。

这是为了让它不那么臃肿，让您可以选择删除可能大多数人都不使用的遗留模块。

Answer 3

Jigsee和OSGi试图解决同样的问题：如何允许更粗粒度的模块在屏蔽其内部的同时进行交互。

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

这是一个例子：Spring和Hibernate。两者都依赖于第三方JAR CGLIB，但它们使用该JAR的不同且不兼容的版本。如果您依赖标准JDK，您能做些什么？包括Spring想要的版本会破坏Hibernate，反之亦然。

但是，如果您有一个更高级别的模型，比如Jigsaw，那么您可以轻松地在不同的模块中管理不同版本的JAR。将其视为更高级别的包。

如果您从GitHub源代码构建Spring，您也会看到它。他们重做了框架，使其由几个模块组成：核心、持久性等。您可以选择应用程序需要的最小模块依赖集，而忽略其余模块。它过去是一个Spring罐，里面有所有的。类中的文件。

更新：五年后，拼图可能仍有一些问题需要解决。