跳到内容
1.Nicolai Parlog编写的The Java Module System
1.1.推荐阅读
2.Jigsaw项目
2.1.开发持续了将近十年
3.关注点分离
3.1.separation of concern,SoC
3.2.将单体的计算机程序分解为一个个相互独立的特性
4.信息隐藏
4.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.希望一个包中的某个类或接口可以被另外一个包中的类或接口访问，那么只能将它声明为public
6.1.2.增大了系统受攻击的可能性，因为更多的代码都暴露在了攻击面下
6.2.类的路径
6.2.1.对同一个类，无法指定到底使用类路径上的哪一个版本，因为根本无法通过路径指定版本
6.2.2.类路径也不支持显式的依赖
6.2.2.1.“类路径地狱”问题导致我们很难对应用的依赖性进行分析
6.2.2.2.ClassNotFound Exception
6.2.3.Maven或者Gradle这样的构建工具可以帮助解决这一问题
7.单体型的JDK
7.1.无论你是否在你的应用中使用了CORBA，对CORBA的支持默认都打包在JDK之中
7.2.Java 8引入了精简配置（compact profile
7.3.sun.misc.Unsafe类
7.3.1.设计之初并不期望被JDK之外的任何代码访问或使用
7.3.2.这个类被好几个流行的类库（包括Spring、Netty、Mockito等）所使用
7.4.导致很高的维护成本并限制了Java的演进
8.开放服务网关协议
8.1.open service gateway initiative, OGSi
8.2.最早提出于2000年，直到Java 9诞生，一直都是实现基于JVM的模块化应用的事实标准
8.3.OGSi认证支持的框架
8.3.1.Apache Felix
8.3.2.Equinox
8.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 to
9.6.1.可以限制哪些用户能访问哪些导出的包
9.7.requires子句
9.7.1.可以指定本模块对其他模块的依赖
9.7.2.所有的模块都依赖于名叫java.base的平台模块
9.7.2.1.不需要显式声明
9.8.open和opens
9.8.1.能够让其他模块以反射的方式访问它所有的包
9.8.2.open限定符在模块的可见性方面没有特别的效果，唯一的作用就是允许对模块进行反射访问
9.9.uses和provides
9.9.1.使用provides子句创建服务供应方，使用users子句创建服务消费者
