java 拼图_功能项目拼图将Java 9引入

java 拼图

因此，拼图项目...我们已经对此颇为了解，但尚未看到计划如何兑现其承诺的细节。这篇文章将精确地做到这一点，并介绍项目的核心概念和功能。

系列

这篇文章是正在进行的有关拼图项目系列的一部分。按照推荐的顺序（不同于发布顺序），它们是：

动机和目标
核心概念和功能（即将推出）
如何破坏您的代码
历史，结构和当前状态（即将发生）
动手指南（即将在EA版本包含JSR 376的情况下发布）

相应的标记列出了有关该主题的更多文章。

总览

第一部分将介绍Jigsaw项目的核心概念，即模块。然后，我们将看到它们将具有哪些功能，以及如何计划它们与现有代码和工具进行交互。

本文的主要来源是Jigsaw项目和JSR 376的要求。尽管这些文档基于全面的探索阶段，因此非常成熟，但它们仍可能会发生更改。接下来的事情是一成不变的。

核心概念

有了Project Jigsaw，Java语言将得到扩展以具有模块概念。

[模块]是由代码和数据组成的自描述程序组件。模块必须能够包含组织成包的Java类和接口，以及动态加载库形式的本机代码。模块的数据必须能够包含静态资源文件和用户可编辑的配置文件。
Java平台模块系统：要求（草案2）

为了对模块有所了解，您可以将每个Apache Commons （例如Collections或IO）， Google Guava或（ cough ） LibFX之类的知名库都视为模块。好吧，根据作者想要拆分的粒度，每个人实际上可能都包含几个模块。

对于应用程序也是如此。它可能是单个整体模块，但也可能分成多个模块。我想说一个项目的规模和凝聚力将是决定该项目可组成的模块数量的主要决定因素。当然，它的实际体系结构和实现是否允许这是另外一个故事。

计划是模块将成为开发人员中用来组织代码的常规工具。

开发人员已经在语言方面考虑了标准种类的程序组件，例如类和接口。模块应该只是另一种程序组件，像类和接口一样，它们应该在程序开发的所有阶段都具有含义。

Mark Reinholds –拼图项目：聚焦全局

然后可以在开发的所有阶段（即在编译时，构建时，安装时或运行时）将模块组合成各种配置。它们将对像我们这样的Java用户可用（在这种情况下有时称为开发人员模块 ），但也将用于剖析Java运行时本身（通常称为平台模块 ）。

实际上，这是有关如何将JDK模块化的当前计划：

jdk-tr

特征

那么模块如何工作？查看计划中的功能将有助于我们对它们有所了解。

请注意，即使以下各节将介绍很多功能，也不会在所有可用详细信息中进行讨论，也不会完整列出这些功能。如果您想了解更多信息，可以从方括号中的链接开始，或者立即查看Jigsaw项目和JSR 376的完整要求。

依赖管理

为了解决JAR / classpath难题，Jigsaw项目实现的核心功能之一是依赖管理。

声明与决议

一个模块将声明编译和运行其所需的其他模块[ 依赖项 ]。模块系统将使用它来传递性地标识编译或运行初始一个[ 分辨率 ]所需的所有模块。

也有可能不依赖于特定模块而是依赖于一组接口。然后，模块系统将尝试查找实现这些接口并因此满足依赖项[ services ， binding ]的模块。

版本控制

将支持版本控制模块[ 版本控制 ]。他们将能够指示自己的版本（只要完全排序即可使用几乎任何格式），以及对其依赖项的约束。在任何阶段都可以覆盖这两条信息。模块系统将在每个阶段强制配置满足所有约束。

Project Jigsaw不一定会在单个配置中支持模块的多个版本 [ 多个版本 ]。但是，等等，这如何解决JAR地狱？好问题。

模块系统也可能未实现版本选择。因此，当我在上面写道“模块系统[将]识别编译或运行所需的所有模块”时，这是基于每个模块只有一个版本的假设。如果有多个，则上游步骤（例如，开发人员，或者更可能是他使用的构建工具）必须进行选择，并且系统将仅验证其满足所有约束[ 版本选择 ]。

封装形式

从同一类路径加载的所有其他代码将自动提供JAR中的所有公共类和接口。对于模块而言，情况将有所不同，在这些模块中，系统将在所有阶段强制执行更强的封装（无论是否存在安全管理器）。

一个模块将声明特定的软件包，并且仅导出其中包含的类型。这意味着只有它们将对其他模块可见并且可访问。更严格地说，类型将仅导出到明确依赖于包含它们的模块的那些模块[ export ， encapsulation ]。

为了帮助开发人员（尤其是那些模块化JDK的开发人员）保持较小的导出API界面，将存在其他发布机制。这将允许一个模块指定要导出的其他软件包，但只能导出到一组也指定的模块。因此，尽管使用“常规”机制，导出模块将不知道（也不关心）谁访问了软件包，但该模块将允许它限制可能的依赖项集合（合格的出口）。

模块也可以重新导出其依赖的模块的API（或其部分）。这将允许在不破坏依赖关系的情况下拆分和合并模块，因为原始模块可以继续存在。他们将导出与以前完全相同的程序包，即使它们可能不包含所有代码[ 重构 ]。在极端情况下，所谓的聚合器模块可能根本不包含任何代码，并且只能作为一组模块的抽象。实际上，来自Java 8的紧凑配置文件就是这样。

不同的模块将能够包含相同名称的程序包，甚至允许它们导出它们[ export ， non-interference ]。

Oracle将利用这一机会使所有内部API不可用。这将是采用Java 9的最大障碍，但肯定会树立正确的道路。首先，由于关键代码现在已对攻击者隐藏，因此它将大大提高安全性。这也将使JDK的可维护性大大提高，从长远来看，这将有回报。

配置，阶段和保真度

如前所述，在开发的所有阶段都可以将模块组合成各种配置。对于平台模块而言，这是正确的，可用于创建与完整JRE或JDK，Java 8中引入的紧凑配置文件相同的映像，或仅包含一组指定模块（及其传递依赖项）的任何自定义配置[ JEP 200；目标 ]。同样，开发人员可以使用该机制来组合自己的模块化应用程序的不同变体。

在编译时，正在编译的代码将仅看到由一组配置的模块[ 编译时配置 ]导出的类型。在构建时，一个新工具（大概称为JLink ）将允许创建二进制运行时映像，该映像包含特定模块及其依赖项[ 构建时配置 ]。在启动时，可以使图像看起来像仅包含其模块的子集[ 启动时配置 ]。

在每个阶段，都可以用较新的版本替换实现认可标准或独立技术的模块 [ 可升级模块 ]。这将替换已弃用的认可标准覆盖机制和扩展机制。

除非由于特殊原因[ 保真 ]不可能，否则模块系统的所有方面（如依赖管理，封装等）在所有阶段都将以相同的方式工作。

所有模块特定的信息（例如版本，依赖项和包导出）都将在代码文件中表示，而与IDE和构建工具无关。