Java9发布已经有一年了，跟Java8相比，从目录对比就看得出来差别相当大。
实际上Java9最大的变化就是JDK模块化（Modular）。
那么，模块化的目的是什么呢？
官方的说法是：
之前版本的Java存在一些问题：
1、JDK和JRE作为一个整体部署，体积太大（JDK8只是rt.jar一个包就超过60MB）。体积大有如下缺点：
（1）下载慢，部署慢。
（2）内存较小的设备无法部署。这跟Java从诞生时的口号Write once , Run anywhere不符。
（3）大量部署在云端，累计占用的内存非常可观。
2、访问控制粒度不够细。
所有public关键字定义的属性或者方法，在任何地方都可以被调用，这影响了代码的封装性。例如在import了sun.*之后，sun.*下面大量用不着的API也暴露出来了（最直观的例子就是使用IDE时，在对象名后面输入点“.”自动会弹出所有public的属性和方法清单以供选择）。
另外，之前的权限控制针对的是类与类之间的关系，模块化针对的是组件之间的控制。模块化的目标之一是，利用一组逻辑独立的组件搭建出完整的系统。
3、Dependency Hell。
依赖地狱是一个诙谐的说法，指的是由Java类加载机制的特性引发的一系列问题，包括JAR包冲突、运行时类缺失。
为了解决以上这些问题，Java9引入了模块系统JPMS。
【说明】
1、JAR包冲突
有时classpath中不同的JAR包会包含限定名完全相同的类。造成这种现象的原因有很多，例如一个Fat JAR包含了某个类A的版本v1，另一个Fat JAR包含了该类A的另一个版本v2，这时就会导致同一个类的两个版本冲突。
JVM的类加载机制会从classpath中第一个包含某个类的JAR包里加载该类，这个被加载的类将会“屏蔽”该类的其他版本（可能真正需要的却是这个版本），使这些类变得不可用。这样会导致程序的行为不是我们预想的那样，结果可能很糟。
2、运行时类缺失（这是我自己的说法）
有些依赖如第三方JAR包，Java运行时系统只有在真正需要访问这些JAR包时才能检测到它所依赖的某些类找不到。这时运行时系统将会抛出NoClassDefFoundError异常，进而导致正在运行的应用程序崩溃。
3、Fat JAR
Fat JAR是将所有依赖和资源文件都打包成一个JAR包，它可能包含了另一个它依赖的JAR包。
