java8 模块化_JEP 200：模块化JDK

原文链接   译者：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。它最初的目的是制造实现平台可以更容易地拓展下至小设备，提高保护和可维护性，可以提高程序行为和提供开发者更好的工具为了更大的程序开发。

描述

设计原则

模块化结构提出了实现下面的原则：

标准模块化，那些明确规定的是由JCP支配，必须有名字并使用“java.”作为开头。

所有其他模块仅仅是JDK的你一部分，和必须有名字并起始为“.jdk”。

如果一个模块导出一个包包含public或protected成员，反过来，参考一种从其他模块，第一个模块必须给予暗示并可读的给到第二个，通过公共需求。(这确定方法调用链工作在明显的方式)

一个标准模块可能包含标准和不标准的API包。如果标准模块导出一份标准API包那么导出可能是合格的。如果标准模块导出了一个标准非标准API包那么就必须合格。在任何情况下，如果一个标准模块导出包有质量那么导出必须是一些JDK的模块。如果标准模块是一个Java SE模块等，为了提出包含Java SE平台明确规定，那么它就必须不能导出任何不是SE API的包，至少没有什么限制的。、

一个标准的模块可以依赖前面一个或者多个不标准模块。这不必授予暗指的并可读地对于任何非标准模块。如果它是Java SE模块那么它不必授予可读的对于任何非SE模块。

一个不标准模块不必导出任何标准的API包。一个不标准的模块可能授予暗指的可读性到一个标准的模块。

一个重要结果就是准则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是：