「JDK 11」关于 Java 模块系统，看这一篇就够了

继 2014 年 3 月 Java 8 发布之后，时隔 4 年，2018 年 9 月，Java 11 如期发布，其间间隔了 Java 9 和 Java 10 两个非LTS（Long Term Support）版本。作为最新的LTS版本，相比 Java 8，Java 11 包含了模块系统、改用 G1 作为默认 GC 算法、反应式流 Flow、新版 HttpClient 等诸多特性。作为 JDK 11 升级系列的第一篇，本文将介绍此次升级最重要的特性——模块系统。

1、模块系统简介

如果把 Java 8 比作单体应用，那么引入模块系统之后，从 Java 9 开始，Java 就华丽的转身为微服务。模块系统，项目代号 Jigsaw，最早于 2008 年 8 月提出（比 Martin Fowler 提出微服务还早 6 年），2014 年跟随 Java 9 正式进入开发阶段，最终跟随 Java 9 发布于 2017 年 9 月。

那么什么是模块系统？官方的定义是A uniquely named, reusable group of related packages, as well as resources (such as images and XML files) and a module descriptor.如图-1所示，模块的载体是 jar 文件，一个模块就是一个 jar 文件，但相比于传统的 jar 文件，模块的根目录下多了一个module-info.class 文件，也即 module descriptor。 module descriptor 包含以下信息：

• 模块名称
• 依赖哪些模块
• 导出模块内的哪些包（允许直接 import 使用）
• 开放模块内的哪些包（允许通过 Java 反射访问）
• 提供哪些服务
• 依赖哪些服务

图-1: Java 9 Module

也就是说，任意一个 jar 文件，只要加上一个合法的 module descriptor，就可以升级为一个模块。这个看似微小的改变，到底可以带来哪些好处？在我看来，至少带来四方面的好处。

第一，原生的依赖管理。有了模块系统，Java 可以根据 module descriptor计算出各个模块间的依赖关系，一旦发现循环依赖，启动就会终止。同时，由于模块系统不允许不同模块导出相同的包（即 split package，分裂包），所以在查找包时，Java 可以精准的定位到一个模块，从而获得更好的性能。

第二，精简 JRE。引入模块系统之后，JDK 自身被划分为 94 个模块（参见图-2）。通过 Java 9 新增的 jlink 工具，开发者可以根据实际应用场景随意组合这些模块，去除不需要的模块，生成自定义 JRE，从而有效缩小 JRE 大小。得益于此，JRE 11 的大小仅为 JRE 8 的 53%，从 218.4 MB缩减为 116.3 MB，JRE 中广为诟病的巨型 jar 文件 rt.jar 也被移除。更小的 JRE 意味着更少的内存占用，这让 Java 对嵌入式应用开发变得更友好。

图-2: The Modular JDK

第三，更好的兼容性。自打 Java 出生以来，就只有 4 种包可见性，这让 Java 对面向对象的三大特征之一封装的支持大打折扣，类库维护者对此叫苦不迭，只能一遍又一遍的通过各种文档或者奇怪的命名来强调这些或者那些类仅供内部使用，擅自使用后果自负云云。Java 9 之后，利用 module descriptor 中的 exports 关键词，模块维护者就精准控制哪些类可以对外开放使用，哪些类只能内部使用，换句话说就是不再依赖文档，而是由编译器来保证。类可见性的细化，除了带来更好的兼容性，也带来了更好的安全性。

图-3: Java Accessibility

第四，提升 Java 语言开发效率。Java 9 之后，Java 像开挂了一般，一改原先一延再延的风格，严格遵循每半年一个大版本的发布策略，从 2017 年