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模块化的当前计划：

特征

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

请注意，即使以下各节将介绍很多功能，也不会在所有可用详细信息中进行讨论，也不会完整列出这些功能。 如果您想了解更多信息，可以从方括号中的链接开始，或者立即查看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和构建工具无关。

性能

整个程序优化技术

在具有强封装性的模块系统中，自动推断将要使用特定代码段的所有位置要容易得多。 这使得某些程序分析和优化技术更加可行：

快速查找JDK和应用程序类； 早期字节码验证； 主动内联例如lambda表达式和其他标准编译器优化； 构造特定于JVM的内存映像，该映像可以比类文件更有效地加载； 提前将方法主体编译为本地代码； 并删除未使用的字段，方法和类。

拼图项目：目标与要求（草案3）

这些被标记为整个程序的优化技术 ，并且至少有两种这样的技术将在Java 9中实现。它还将包含一个工具，该工具可以分析给定的一组模块，并应用这些优化来创建性能更高的二进制映像。

注解

自动发现带注释的类（例如Spring允许）目前需要扫描某些指定包中的所有类。 这通常是在程序启动时完成的，可能会大大降低它的速度。

模块将具有一个API，允许调用者使用给定的注释标识所有类。 一种设想的方法是创建此类的索引，该类的索引将在模块编译时创建[ 注解检测 ]。

发布时间由droetker0912下， CC-BY-NC-SA 2.0 。

与现有概念和工具的集成

诊断工具（例如堆栈跟踪）将被升级，以传达有关模块的信息。 此外，它们将被完全集成到反射API中，该反射API可以以与类[ 反射，调试和工具 ]相同的方式来操作它们。 这将包括可以在运行时反映和覆盖的版本信息[ 反射API中的版本字符串 ， 可覆盖的版本信息 ]。

该模块的设计将允许“以最小的麻烦”使用构建工具 [ 构建工具 ]。 模块的编译形式可以在类路径上使用，也可以作为模块使用，这样库开发人员就不必为类路径和基于模块的应用程序创建多个工件（ 多模式工件 ）。

还计划与其他模块系统（尤其是OSGi）进行互操作 [ 互操作 ]。

即使模块可以从其他模块隐藏包，也可以测试所包含的类和接口[ 白盒测试 ]。

特定于操作系统的包装

该模块系统在设计时考虑了软件包管理器文件格式“ RPM，Debian和Solaris IPS”。 开发人员不仅可以使用现有工具从一组模块中创建特定于操作系统的软件包。 这样的模块也将能够调用以相同机制安装的其他模块[ 模块包装 ]。

开发人员还将能够将构成应用程序的一组模块打包到特定于OS的软件包中，“最终用户可以按照目标系统的惯常方式来安装和调用这些软件包”。 在上面的基础上，只需打包目标系统上不存在的那些模块即可[ 应用程序打包 ]。

动态配置

运行中的应用程序可以创建，运行和发布多个隔离的模块配置[ 动态配置 ]。 这些配置可以包含开发人员和平台模块。

这对于诸如IDE，应用程序服务器或Java EE平台的容器体系结构将非常有用。

反射

我们已经看到Project Jigsaw将带给Java 9的大多数功能。它们都围绕新的模块核心语言概念展开。

在日常编程中，最重要的可能是跨不同阶段的依赖关系管理，封装和配置。 改进的性能始终是一个不错的选择。 然后，需要投入与现有工具和概念的合作，例如反射，诊断，构建工具和特定于操作系统的打包。

等不及要尝试了？ 我也不行！ 但是，我们必须等到JSR 376进一步问世，然后才能将带有Project Jigsaw的JDK9或JDK 9的早期访问版本实际包含模块系统。 当它最终完成时，您将在此处阅读有关内容。

翻译自: https://www.javacodegeeks.com/2015/07/the-features-project-jigsaw-brings-to-java-9.html

java 拼图