1.Nicolai Parlog编写的The Java Module System1.1.推荐阅读2.Jigsaw项目2.1.开发持续了将近十年3.关注点分离3.1.separation of concern,SoC3.2.将单体的计算机程序分解为一个个相互独立的特性4.信息隐藏4.1.information hiding4.2.要求设计时尽量隐藏实现的细节4.2.1.隐藏内部实现细节能帮你减少局部变更对程序其他部分的影响4.2.2.有效地避免变更传递4.2.3.与应用的其他部分没有任何耦合，对这段代码内部实现的更迭不会对应用的其他部分产生影响4.3.通过private关键字，借助编译器验证组件中的类是否封装良好4.4.Java 9出现之前，编译器无法依据语言结构判断某个类或者包仅供某个特定目标访问5.模块5.1.具备内聚特质的一组代码，它与其他模块代码之间很少有耦合5.2.通过模块组织类，可以帮助你清晰地表示应用程序中类与类之间的可见性关系5.3.Java的包并未从本质上支持模块化6.Java9之前模块化的局限性6.1.有限的可见性控制6.1.1.希望一个包中的某个类或接口可以被另外一个包中的类或接口访问，那么只能将它声明为public6.1.2.增大了系统受攻击的可能性，因为更多的代码都暴露在了攻击面下6.2.类的路径6.2.1.对同一个类，无法指定到底使用类路径上的哪一个版本，因为根本无法通过路径指定版本6.2.2.类路径也不支持显式的依赖6.2.2.1.“类路径地狱”问题导致我们很难对应用的依赖性进行分析6.2.2.2.ClassNotFound Exception6.2.3.Maven或者Gradle这样的构建工具可以帮助解决这一问题7.单体型的JDK7.1.无论你是否在你的应用中使用了CORBA，对CORBA的支持默认都打包在JDK之中7.2.Java 8引入了精简配置（compact profile7.3.sun.misc.Unsafe类7.3.1.设计之初并不期望被JDK之外的任何代码访问或使用7.3.2.这个类被好几个流行的类库（包括Spring、Netty、Mockito等）所使用7.4.导致很高的维护成本并限制了Java的演进8.开放服务网关协议8.1.open service gateway initiative, OGSi8.2.最早提出于2000年，直到Java 9诞生，一直都是实现基于JVM的模块化应用的事实标准8.3.OGSi认证支持的框架8.3.1.Apache Felix8.3.2.Equinox8.4.OGSi与新的Java 9模块系统之间并不是完全互斥的8.4.1.只有小部分的重叠8.4.2.可以在同一个应用之中共存8.4.3.OGSi所覆盖的范畴要大得多8.5.OGSi中每一个bundle都有单独的类加载器8.5.1.Jigsaw中每个应用仅使用一个类加载器8.5.2.解决版本选择问题并不是Java 9模块系统设计的出发点，所以它不支持版本9.Java模块系统基础9.1.模块化是对抗软件腐臭的利器9.1.1.随着项目的不断演进，更多的内部实现被加入进来，这时封装和划分的价值就变得越来越明显9.2.命名9.2.1.互联网域名规范的逆序9.2.2.模块名应该与它导出的主要API的包名保持一致9.3.Java 9的模块9.3.1.提供粒度更细的控制9.3.1.1.可以设定哪个类能够访问哪个类9.3.1.2.这种控制是编译期检查的9.3.2.位于模块路径上且没有提供module-info文件的JAR文件会被Java 9作为自动模块处理9.3.3.Maven支持按照Java 9模块系统构建的应用9.4.模块中的所有内容都是被封装的9.4.1.模块系统使用白名单的方式帮助你进行更严格的封装控制9.4.2.显式地声明你愿意将哪些内容提供给别的模块访问9.4.3.避免你由于偶然的机会开放一些内部接口给外部使用，可能导致你的系统被攻破9.5.exports子句9.5.1.它声明的这些包会变为公有类型，可以被其他模块访问和调用9.6.exports to9.6.1.可以限制哪些用户能访问哪些导出的包9.7.requires子句9.7.1.可以指定本模块对其他模块的依赖9.7.2.所有的模块都依赖于名叫java.base的平台模块9.7.2.1.不需要显式声明9.8.open和opens9.8.1.能够让其他模块以反射的方式访问它所有的包9.8.2.open限定符在模块的可见性方面没有特别的效果，唯一的作用就是允许对模块进行反射访问9.9.uses和provides9.9.1.使用provides子句创建服务供应方，使用users子句创建服务消费者
