Oracle 发布 Java 模块系统状态报告

Oracle Java 平台组首席架构师 Mark Reinhold 发表了一份关于模块化系统的情况的报告，强调了模块化的目标是什么。由于和已经存在的框架存在明显的重复，特别是 OSGi，报告引起发了人们的讨论。

正如报告中所解释的，以及在 JSR-376 和模块化系统项目主页中完整的详细说明，模块化系统是为了解决当前 Java 访问模型中的两个疏漏：

• 可靠的配置：当前一个组件通过类路径访问另一个组件的类时相当容易出错，特别是尝试使用不在类路径里面或者存在多个版本的类的时候。
• 强封装：没有办法去限制特定组件暴露给其他组件的类，外部能访问所有的公共类。

完整的细节能够在报告和 InfoQ 之前的文章中找到，总的来说，每一个组件通常（但不一定）作为一个 jar 文件，其中包含了如下结构的模块描述文件 module-info.java：

module com.foo.bar {
 
  requires com.foo.baz;
 
  exports com.foo.bar.alpha;
 
  exports com.foo.bar.beta;
 
}

文件结构中包含一行或多行 exports 用于指出能够被其他组件访问的包，零行或多行 requires 用于指出自身需要访问的其他模块。该系统提供了方法用于在编译时评估访问类型是否具有正确的可见性（例如声明为公共类并被所需组件导出），并在运行时评估必需的模块是否可用，而不需要去检查完整的类路径。类似于 OSGi 中的清单文件。

OSGi 的背景

OSGi 是一个基于 Java 的模块化系统和服务化平台，实现了一个完整的动态的组件模型。从 1998 年在 JSR-8 第一次提出，在随后的审核中被延迟发布（最近一次是 2014 年），OSGi 定义了 bundle（类似模块），采用包含如下的 MANIFEST.MF 文件的 JAR 文件的形式：

Bundle-Name: Hello World
 
Bundle-SymbolicName: org.wikipedia.helloworld
 
Bundle-Description: A Hello World bundle
 
Bundle-ManifestVersion: 2
 
Bundle-Version: 1.0.0
 
Bundle-Activator: org.wikipedia.Activator
 
Export-Package: org.wikipedia.helloworld;version="1.0.0"
 
Import-Package: org.osgi.framework;version="1.3.0"

（例子来源于 Wikipedia）

显而易见的，尽管格式不一样，但是目的表现的和 Java 模块系统很相似。的确，Java 平台模块系统和 OSGi 之间的相似性，在 2005 年提出的 JSR-277，“Java 模块系统”中，初次尝试模块化 Java 时就已经被注意到了。最初瞄准的 Java 7，JSR-277 专注简化分发和执行 Java 程序包。尽管有和 JSR-376 几乎一样的名字，但两者最初的目标有着细微差别；虽然它的任务是修复“可靠的配置”问题，但是它并不试图解决“强封装”的问题。相对于 JSR-376，它也尝试增加一个版本模型到 Java 程序包中。这些目标和 OSGi 提供的功能之间的相似性是完全足够让作者在最初考虑把 OSGi 作为一个解决方案，放弃的原因考虑为 OSGi 的版本控制太弱了。

不久之后创建的 JSR-294 的目标是实现“改进 Java 程序语言的模块性支持”。同时针对 Java 7，JSR-294 新增了模块概念（所谓的“超级包”）来修复强封装的问题；这个概念匹配了当前的 Java 平台模块系统项目。当 Java 7 的目标被放弃时，JSR-277 和 JSR-294 从 2012 年开始被冻结，由 JSR-376 代替。

OSGi 和模块化 Java 的另一个关联能在 JSR-291 中找到，“Java SE 的动态组件支持”（本质上是 OSGi 服务平台发布的第四版）。JSR-291 参考了 JSR-277，作为最早的 Java 模块系统，来主动区分两者之间的不同作用：JSR-277 关注 Java 中使用的静态模块定义，而 JSR-291 关注运行时动态组件的加载和卸载。

最后，JSR-376 也参考了 OSGi，放弃它作为有效解决方案的主要原因是因为它的范围远远大于 Java 框架模块系统规范。

综上所述，多数人难以区分新的模块系统和 OSGi 是正常的。但是，模块系统和 OSGi 相互补充，用以服务于不同的目标，OSGi 作为一个构建于 Java 之上的框架，在一个持续运行的应用中，创建了一个用以动态管理 bundle 的环境，而模块系统作为 Java 本身的新能力能够更紧密更简单的控制静态模块。

Java 平台模块系统和 OSGi 的区别

为了更好的理解这一点，InfoQ 请教了 Holly Cummins，《Enterprise OSGi in Action》的作者之一。不过以下内容并不会彻底说清楚 Java 平台模块系统和 OSGi 之间的差异，只是为读者提供一个基本的理解关于两者目标的区别。

一方面，Java 新的模块系统将会提供更简单的方式在编译时检查包和类的可见性，但是当我们询问 OSGi 的 bundle 是否能用相同的方式使用时，Holly 表示“答案是相当的复杂”。

OSGi 通过 bundle 的清单文件来描述依赖，有两种基本方式来创建清单文件:“代码优先”和“清单文件优先”。代码优先方式（使用 bnd 工具，和 maven bundle 插件），并不会在编译时检查依赖列表，实际上它是在编译时生成的。在通常方式的编译过程中，工具会根据编译时的依赖统计出运行时的依赖。另一种方式是清单文件优先，通过 Eclipse PDE 工具来使用。在这种方式中，依赖被声明在清单文件中，Eclipse IDE 会使用这份清单文件统计出你的代码能访问的类，并高亮缺失的依赖。PDE 命令行构建和一个叫做 Tycho 的 Maven 插件，都会在编译时检查依赖关系。但是，请注意 OSGi 自己并不会检查可见性，而是通过 PDE 自带的工具；因为不是所有使用 PDE 的团队都会使用其中的工具，有时候可能会在编译时造成缺少依赖。

新的模块系统的另一个重要方面是能够限定指定包对模块的导出，这是很有用的当一批相互关联的模块需要互相访问，但却不能访问其他内容时。正如 Mark Reinhold 在报告中指出的，这能够用以下语法来实现：

module java.base {
  ...
  exports sun.reflect to
      java.corba,
      java.logging,
      java.sql,
      java.sql.rowset,
      jdk.scripting.nashorn;
}

OSGi 最初并没有这个能力，但增加之后能够让它比模块系统的目标走的更远。Holly 解释道，“所有的 bundle 都能够注册成一个解析拦截器，用以过滤匹配，因此包只会暴露给指定的 bundle。当导出声明了确定的元数据的包给 bundle 时，你能够使用相同的机制来预测，或者只是在每周二疯狂的导出包”。

查看英文原文： Oracle Publishes Report on the State of Java’s Module System

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。