几周前，我写了一篇关于Jigsaw项目如何破坏现有代码的文章 。 那么，我们能得到什么回报呢？ 让我们看一下项目解决的痛点及其在Java 9中解决问题的目标。

系列

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

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

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

总览

在查看项目目标之前，我们将首先介绍激发创建拼图项目的痛点。

主要资源包括JSR 376和Java 9和Beyond ，由Mark Reinhold（Oracle Java平台组首席架构师）在EclipseCon 2015上发表。

痛点

Jigsaw项目旨在解决几个难题。

JAR /类路径地狱

很多人都写过有关类路径地狱和JAR地狱的文章 ，因此无需重复。

当运行库解决依赖关系的方式与开发人员认为的不同时，就会出现此问题。 例如，这可能导致运行版本错误的库。 寻找造成这种情况的原因可能非常令人不快（因此，乐观的说法）。

发生这种情况的原因是Java运行时加载类的方式。 该机制很脆弱（例如，取决于顺序），可能很复杂（例如，具有多个嵌套的类加载器），因此很容易出错。 此外，运行时无法分析需要哪些类，因此只有在运行时才能发现未实现的依赖项。

通常也不可能满足对同一库的不同版本的依赖。

跨封装的弱封装

Java的可见性修饰符非常适合在同一包中的类之间实现封装。 但是跨程序包边界只有一种可见性： public 。

由于类加载器将所有已加载的程序包折叠成一个大泥球，因此所有其他类都可以看到所有公共类。 因此，无法创建在整个JAR中可见但不在其外部可见的功能。

这使得正确地模块化系统非常困难。 如果模块的不同部分需要某些功能（例如，系统的库或子项目），但在模块外部不可见，则实现此功能的唯一方法是将它们全部放入一个包中（因此，能见度可以使用）。 这有效地删除了代码以前可能拥有的任何结构。

手动安全

跨软件包边界的弱封装的直接后果是，与安全相关的功能将暴露给在同一环境中运行的所有代码。 这意味着恶意代码可以访问关键功能，从而可能使其绕过安全措施。

从Java 1.1开始，这是由黑客阻止的：在与安全性相关的代码中的每个代码路径上均调用java.lang.SecurityManager.checkPackageAccess并检查是否允许访问。 或更准确地说：应该在每个这样的路径上调用它。 忘记这些调用会导致一些漏洞，这些漏洞过去困扰着Java。

启动表现

Java运行时加载当前所需的类并及时编译常用的类需要一段时间。

原因之一是，类加载对类路径上的所有JAR执行线性扫描。 同样，识别所有出现的特定批注要求检查类路径上的所有类。

刚性Java运行时

在Java 8之前，无法安装JRE的子集。 所有Java安装都支持例如XML，SQL和Swing，许多用例根本不需要。

尽管这与中型计算设备（例如台式机或笔记本电脑）无关紧要，但对于最小的设备（例如路由器，电视盒，汽车以及所有其他使用Java的角落和缝隙），显然很重要。 在当前的容器化趋势下，它也可能与服务器相关，减少图像的占用空间将降低成本。

Java 8带来了紧凑的概要文件 ，这些概要文件定义了Java SE的三个子集。 他们减轻了问题，但没有解决。 紧凑的概要文件是固定的，因此无法满足部分JRE当前和将来的所有需求。

发布时间由里卡多Cuppini下， CC-BY-NC-ND 2.0 。

拼图项目的目标

拼图项目旨在通过引入一种语言级机制来模块化大型系统来解决上述问题。 此机制将在JDK本身上使用，开发人员也可以在自己的项目上使用。 （下一篇文章中有关计划功能的更多详细信息。）

重要的是要注意，并非所有目标对于JDK和我们的开发人员都同样重要。 许多代码与JDK更为相关，并且大多数代码不会对日常编码产生巨大影响（与lambda表达式或默认方法不同 ）。 他们仍将改变大型项目的开发和部署方式。

可靠的配置

各个模块将声明其对其他模块的依赖性。 运行时将能够在编译时，构建时和启动时分析这些依赖关系，因此可以因缺少或冲突的依赖关系而快速失败。

强封装

Project Jigsaw的主要目标之一是使模块仅导出特定的软件包。 所有其他软件包均为该模块专用。

模块专用的类应该与专用字段专用于类的方式完全相同。 换句话说，模块边界不仅应确定类和接口的可见性，还应确定其可访问性。

马克·雷因霍尔德（Mark Reinhold）–拼图项目：将全局视为焦点

模块对库或其他模块的依赖关系也可以保持私有。 因此，两个模块可以使用同一库的不同版本，每个模块都将其自身依赖于该代码。 然后，运行时将版本分开，从而防止冲突。

改进的安全性和可维护性

模块内部API的强大封装可以大大提高安全性和可维护性。

这将对安全性有所帮助，因为关键代码现在已从不需要使用它的代码中有效地隐藏了。 由于模块的公共API可以更容易地保持较小的尺寸，因此使维护更加容易。

随意使用Java SE Platform实现内部的API既有安全风险，又有维护负担。 提议的规范提供的强大封装将允许实现Java SE平台的组件阻止对其内部API的访问。

JSR 376

性能提升

通过明确使用代码的范围，可以更有效地利用现有的优化技术。

当已知某个类只能引用其他一些特定组件中的类，而不引用运行时加载的任何类时，许多提前进行的全程序优化技术可能更有效。

JSR 376

也可以为有关现有注释的代码编制索引，以便无需进行完整的类路径扫描就可以找到此类。

可扩展平台

通过将JDK模块化，用户可以选择自己需要的功能，并创建仅由所需模块组成的自己的JRE。 这将保持Java作为小型设备和容器的关键角色的地位。

拟议的规范将允许Java SE平台及其实现分解为一组组件，开发人员可以将它们组装成仅包含应用程序实际所需功能的自定义配置。

JSR 376

反射

我们已经看到Java在加载类的方式，在庞大且不断增长的，刚性的运行时中封装方面存在一些问题。 Jigsaw项目旨在通过引入一种模块化机制来解决此问题，该机制将应用于JDK，并且也将对用户可用。

它保证了可靠的配置和强大的封装，可以使JAR / classpath成为过去。 它可以用来提高安全性，可维护性和性能。 最后重要的一点是，这将允许用户创建特定于他们自己的Java运行时。

本系列的下一篇文章将讨论Project Jigsaw将带给Java 9的功能。敬请期待！

翻译自: https://www.javacodegeeks.com/2015/06/motivation-and-goals-of-project-jigsaw.html