1.官方Feature
200: The Modular JDK
201: Modular Source Code
260: Encapsulate Most Internal APIs
261: Module System
2.产生背景及意义
谈到 Java 9 大家往往第一个想到的就是 Jigsaw 项目。众所周知，Java 已经发展超过 20 年（95 年最初发布），Java 和相关生态在不断丰富的同时也越来越暴露出一些问题：
①Java 运行环境的膨胀和臃肿。每次JVM启动的时候，至少会有30～60MB的内存加载，主要原因是JVM需要加载rt.jar，不管其中的类是否被classloader加载，第一步整个jar都会被JVM加载到内存当中去（而模块化可以根据模块的需要加载程序运行需要的class）
②当代码库越来越大，创建复杂，盘根错节的“意大利面条式代码”的几率呈指数级的增长。不同版本的类库交叉依赖导致让人头疼的问题，这些都阻碍了 Java 开发和运行效率的提升。
③很难真正地对代码进行封装, 而系统并没有对不同部分（也就是 JAR 文件）之间的依赖关系有个明确的概念。每一个公共类都可以被类路径之下任何其它的公共类所访问到，这样就会导致无意中使用了并不想被公开访问的 API。
④类路径本身也存在问题: 你怎么知晓所有需要的 JAR 都已经有了, 或者是不是会有重复的项呢?
同时，由于兼容性等各方面的掣肘，对 Java 进行大刀阔斧的革新越来越困难，Jigsaw 从 Java 7 阶段就开始筹备，Java 8 阶段进行了大量工作，终于在 Java 9 里落地，一种千呼万唤始出来的意味。
Jigsaw项目（后期更名为Modularity）的工作量和难度大大超出了初始规划。JSR 376 Java 平台模块化系统（JPMS,Java Platform Module System）作为 Jigsaw 项目的核心, 其主体部分被分解成 6 个 JEP(JDK Enhancement Proposals)。
作为java 9 平台最大的一个特性，随着 Java 平台模块化系统的落地，开发人员无需再为不断膨胀的 Java 平台苦恼，例如，您可以使用 jlink 工具，根据需要定制运行时环境。这对于拥有大量镜像的容器应用场景或复杂依赖关系的大型应用等，都具有非常重要的意义。
本质上讲，模块(module)的概念，其实就是package外再裹一层，也就是说，用模块来管理各个package，通过声明某个package暴露，不声明默认就是隐藏。因此，模块化使得代码组织上更安全，因为它可以指定哪些部分可以暴露，哪些部分隐藏。
3.设计理念
模块独立、化繁为简
模块化（以 Java 平台模块系统的形式）将 JDK 分成一组模块，可以在编译时，运行时或者构建时进行组合。
4.实现目标
主要目的在于减少内存的开销
只须必要模块，而非全部jdk模块，可简化各种类库和大型应用的开发和维护
改进 Java SE 平台，使其可以适应不同大小的计算设备
改进其安全性，可维护性，提高性能
5.使用举例
注：IntelliJ IDEA 2017.3支持模块化特性，这里选择此开发环境。
模块将由通常的类和新的模块声明文件（module-info.java）组成。该文件是位于java代码结构的顶层，该模块描述符明确地定义了我们的模块需要什么依赖关系，以及哪些模块被外部使用。在exports子句中未提及的所有包默认情况下将封装在模块中，不能在外部使用。
java 9demo 模块中的ModuleTest类使用如下：
对应在java 9demo 模块的src
下创建module-info.java文件：
requires：指明对其它模块的依赖。
在java9test 模块的指定包下提供类Person：
要想在java9demo模块中调用java9test模块下包中的结构，需要在java9test的module-info.java中声明：
exports：控制着哪些包可以被其它模块访问到。所有不被导出的包默认都被封装在模块里面。
6. 补充说明
关于更多Java 9 模块编程的内容请参考一本书：《Java 9 Modularity》 里面讲的比较详细，介绍了当前Java对jar之间以来的管理是多么的混乱，引入modularity之后的改变会是很明显的差别。
