原文链接 译者：carvendy
JEP 200:模块化JDK
作者 Mark Reinhold
创建 2014/07/22 14:08
更新 2017/03/08 13:58
类型 特性
状态 集成
域 SE
JSR 376
讨论 拼图的开发在openjdk.java.net
努力 XL
持续时间 XL
优先 l
检验人 Alan Bateman, Alex Buckley, Paul Sandoz
支持 Brian Goetz
发行 9
版本 8051618
依赖 JEP 220:模块化运行时镜像
JEP 261:模块系统
JEP 201:模块化源码
概要
使用Java平台模块系统，由JSR 376明确规定和由JEP 261的实现，为了模块化JDK。
目标
划分JDK里面一系列的模块并可以在编译、构建的时候结合在一起，或者运行的时候进入各种各样的配置里面，但是没有限制：
- 配置相应的所有Java SE平台，所有JRE，和所有JDK。
- 配置相应相等的在每个契约配置项定义在Java SE 8；
- 自定义配置包含了只有明确规定的部分模块和通过这些模块传递所需的模块。
这些模块化结构的定义必须在标准模块之间有一个清晰区别，那些明确规定是Java程序社区支配，和模块是具体到JDK。它必须区分模块，模块将被提出包含Java SE平台的明确规定，从而制定了强制性的每个平台的实现，从所有其他模块中。
动机
拼图项目目的是为了设计和实现一个标准模块系统给Java SE 平台和允许系统到平台本身和到JDK。它最初的目的是制造实现平台可以更容易地拓展下至小设备，提高保护和可维护性，可以提高程序行为和提供开发者更好的工具为了更大的程序开发。
描述
设计原则
模块化结构提出了实现下面的原则：
一个重要结果就是准则4和准则5是代码依赖在Java SE模块上，将只能依赖标准的Java SE类型，因此对于所有Java SE平台的实现是便携式的。
模块图
模块化结构JDK可以是虚拟的一个图：每个模块是一个节点，和这里有有向边从一个模块到另外一个如果第一个依赖上面的第二个。所有模块图有很多边界更容易地展示；这里是图的传递性约简，在这些冗余的边界是省略的（点击可以更大）。
附上模块图的旅游指南
- 标准的Java SE 模块是橙色的；非SE模块是蓝色的。
- 如果一个模块依赖上面其他的，和它授予了暗示可读的模块，那么边界从第一个到第二个是可靠的；因此，边界是虚线的。
- 在非常底层的java.base模块，包含本质的类例如 java.lang.Object和java.lang.String。基础模块没有依赖上面的模块，和每个其他模块依赖上面的基础模块。基础模块的边界是比其他的要轻量。
- 在顶层的java.se.module模块，集成 了所有模块包含了Java SE平台，导入模块是Java EE平台明确规定的。这是一个聚合模块的例子，收集和复出口其他模块的内容但是加入了它自己没有内容。一个运行时系统配置包含java.se.ee模块将包含Java SE平台的所有API包。一个模块将提出包含Java SE平台规范，只是如果，它是一个标准模块可以从java.se.ee模块获取。
- java.se 聚合模块集合Java SE平台的部分模块，内容没有和Java EE重叠。
- java.compact1,java.compact2,和java.compact3 聚合模块实现了Java SE 契约配置。这里有一个非标准的jdk.compact3模块因为一个compact3 构建的JDK包含一些非标的SE API包，当其他契约配置构建没执行。
- 其他非标准模块包含调试和服务工具和API（例如：jdk,jdi,jdk.jcmd和jdk.jconsole）,开发工具（例如：jdk.compiler,jdk.javadoc,和jdk.xml.bind）,和各种各样服务提供者（例如：jdk.charsets, jdk.scripting.nashorn, jdk.crypto.ec ),这些是制造可获得其他模块通过存在的java.util.ServiceLoader机制。
- java.smartcardio模块是标准的但是不是Java SE平台规范的一部分，由此可见它的名字前缀是“java.”但是它是蓝色的，和it没有到达java.se模块。
模块图是有效的，一个新类型的API，它将被明确规定的和进化的等。模块的子图基于java.se.ee模块，和所有非SE模块，相应边界移除将被提出包含Java SE 平台规范；它的进化将在此后被JCP支配。图的剩余进化将被未来的JEPs覆盖。在另一面，如果一个是指定作为平常可用的而它将受到进化的约束管制作为其他APIs。移除一个模块或者当改变它，在原则上，将需要公共公告至少提前在一个主发行版本。
一个表格概述所有模块，包含构建Linux/AMD64足迹，这里是可用。
开放版本
当前模块图定义至少有一个知道的缺陷，列表底下。修复版本将在修改内容可能的结果和图结构。
- java.management模块依赖上面的java.rmi，它自己是非平凡的大小和经常不是重要的在嵌入驱动情节；我们看着移动的java.management.remote.rmi API包在自己的模块里面。
测试
单元测试和回归测试在JDK和jtreg中，系带用于运行它们，将增强允许测试被选中的基础模块，那些它们测试和上面它们的依赖，所以任意的JDK模块配置可以被测试。
最初的增强功能测试将用于检查模块的配置集合，确认它是有效的模块定义结合成的，每个模块有预期望的内容和输出预期的API包，和模块有预期依赖关系。
JCK必须被增强地测试模块图的各个方面，那些变成Java SE平台规范的一部分。包含SE模块的名字，它们输出的API包和依赖持有它们，因此SE API包被重新导出。在在平台的实现中，JCK必须被增强测试目前SE模块的任意配置。
风险和假设
模块化结构定义在这里不解决一些重要的用例。如果在JEP实现首次发行中批判用例是不支持的 而我们希望可以它可以在后面的发行中重构模块图、
Java SE方面的模块图定义在JEP，注意，被提出最终的Java SE平台JSR专家组审查代码和标准化。审查代码可能要求对图进一步更改。
依赖
JEP是拼图项目的一部分。其他JEP是：
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/99846.html