相对于以前的版本，Java 9进行了模块化
模块化是良好的软件工程实践的基本原则。 这是一种利用软件产品设计和维护的复杂性的技术。 在Java 9之前，开发人员有责任以最少的工作链帮助来吸收这一原则。 Java 9从JRE和JDK的构建中直接使用了这个想法。 这将通过从开发过程开始将此功能作为食谱来改变编程的范例。 本文试图从Java 9开始的新时代的门槛回顾一下模块化编程的原理。
模块化编程基本上是一种软件设计技术，强调将程序作为具有不同功能的单独组件编写，然后把这些单个组件进行组合以创建一个可用的程序。这些单个组件称为模块。根据Mark Reinhold（模块系统的状态），模块是一个命名的，自我描述的代码和数据集合。模块化编程背后的关键思想是将复杂系统拆分成可管理的部分。各个部分应以不受其他部分影响及以离散功能的方式进行分离。与此相反，通常内置在不分割单个模块中的程序称为单片机程序。单片机程序在性能上可能是高效的，但由于增加了程序的复杂性和大小，使得它们不太容易维护。
现代应用庞大而复杂;它们不适合写为单片程序。然而简单而紧凑的程序，如实现一种算法，选择单片机程序的效果会较好。
优势
如果软件的开发遵循模块化设计，当然，以正确的方式构建，无论从长期来说还是短期来说都有以下几个优点：
因为它包含单个模块，具有很好的可重用性。 一些（或全部）组件可以在任何其他程序中重复使用。
模块化代码比单片代码更可读。
其易于维护和升级，因为各个组件具有很强的独立性。 轻松选择一个并进行必要的更改，并尽可能最小化地修改其他模块。
模块化程序相对容易调试，因为它们的去耦特性可将单个组件隔离以进行快速单元测试。 此外，在集成测试中，可很好的确定问题点而以有效的方式解决。
Java 8及以前版本的模块化编程
模块化的思想接近于使用包和JAR存档。而且，也许最容易获得的例子是Java的部分库。库模块通过组合几个部分形成;每个部分都有离散功能。所以，理解Java中的一个模块意味着 - 它只是一个共同兴趣类和接口的集合，被集中到一个包中并作为JAR文件分发。现在，每个模块都有一个公开接口，意味着是一组导出的API，它提供了外部世界与模块进行通信的手段。因此，被设计为模块外部接口的类或接口可用公共访问修饰符指定。这些类和接口的主要功能提供有API，以便与其他模块交互。另一方面，私有成员是无法访问的，只涉及特定部分的内部处理或日常事项。
但必须明白，Java不是从开始就构建为模块化的，而是可以使用包和JAR存档实现模块化的某些方面。尽管带有JAR的模块通常被设计的较谨慎，它们确有许多固有问题。其中一个具有依赖关系。这意味着Java中的一个模块对一个或多个其他模块有一组依赖关系。这种依赖关系在大多数情况下是不可缺少的，并且作为正确执行模块功能是必需的。
这是模块化编程的基础，尽可能应用Java 9。模块化编程在最需要的时候给出了一个新的漂移思想，这样面向对象编程的混乱在一定程度上变得可控。从那时起，近二十年后，程序员意识到还缺少一些东西。问题常常出现，有投诉等等。模块化和OOP Java之间的结合需要新动力。
拼图项目在Java 8发布之前的某个时候被提出，应该是其最终版本的一部分。但是，其的复杂性构造完全被打破了方式，并且决定其将与稍后版本一起发布该功能。
问题
大多数Java开发人员遇到了一个棘手的小问题，其被称为JAR-hell或Classpath-hell。
Java中的模块化编程有几个问题。 以下是经常遇到的问题列表。 而具体的问题与Java类的加载机制有关。
包含在JAR文件中的类和接口通常与其它包中的类有些重叠，以便正常运行。 这使得他们相互依赖。 因此，一个JAR文件可能依赖于另一个而执行。 Java运行时只是在先前遇到的类路径中加载JAR，而不会考虑多个JAR中可能存在相同的类。
有时，缺少类或接口。 最糟糕的是只是在执行期间才会被发现。 在很多情况下，这会无意中崩溃应用程序，从而导致运行时报错。
另一个令人讨厌的问题是版本不匹配。 依赖于另一个JAR的JAR模块通常不能运行，因为其一个或多个依赖模块必须被升级或降级，以使其与依赖模块的版本相兼容。 （Respite是个外部工具，如Maven和OSGi，它们被广泛用于管理此类依赖性。）
此外，还有其他问题，如Java包没有访问修饰符。 因此，包中的公共类对于任何其他包都是可见的。进而，对于包的全局可见性来说，包的模块化没有什么价值。 直到Java 7，JRE和JDK可以作为一个单一的文物，增加了内存占用，空间使用和下载时间昂贵。
Java9中的模块化
Java 9的模块系统是基于这三个核心思想而开发的：
利用强大的封装
建立良好定义的接口
定义显式依赖关系
要了解Java开发人员使用JRE做什么，就需要理解从Java 8形成的部分构思。Java 8以紧凑的形式介绍了JRE中模块化的构思。 紧凑型配置文件被指定为compact1，compact2和compact3的API库子集。 每个库都包括以下顺序库的一个子集：compact2包含compact1和更多的所有库，compact3包括所有compact2等。因此，每个配置文件实际上是建立在前一个配置文件上。 其优点在于，可以下载和使用所需的库的一部分，而不必使用整个JRE。 在Java 8中，可以在编译时参考配置文件，如下所示：
$ javac -profile compact1 TestProg.java
Java 9将这个构思提升到一个超前水平，并将压缩的配置文件的技术消除。相反，它使用户完全控制要包含在自定义JRE中的模块列表。
Java 9还引入了一个被称为模块的新程序组件。这个新组件被用于界定交互和依赖模块之间明确的界限。这相应于解决类路径问题。一个定义的模块必须明确地声明其对其他模块的依赖性。模块系统将在编译，链接和运行期间验证所有三个阶段中所述的依赖关系。因此，这使得在应用程序崩溃之前消除缺少依赖关系的问题。
模块的可访问性已被改进，并以通过在公开的代码和用于内部实现的代码之间绘制一个明确的界限来强化封装。这样可以解决模块的问题，并防止造成不必要的或意外的更改。一个模块可以清楚地说明它想要暴露给其他模块的公共类型。
随着模块化的诞生，Java 9更具有灵活性和可重用性。
结论
在Java 9之前，JAR文件是最接近模块的东西。 但是，与使用JAR文件相关的许多问题需要被纠正以在Java中使用纯模块化。 在这方面，Java 9有很高的期望。 它有两重责任; 一个，它必须用模块化的新构思以补充JRE和JDK; 二，不能破坏现有的制度。 这意味着除了为Java项目提供新动力外，还应该向后兼容。 现有项目也应能够无缝升级。 无论最终的结果如何，它本质上是一个巨大的努力。 这个旗舰功能肯定会恢复Java的核心，为新型产品开发，部署和封装铺平道路。
