简单模块系统能否拯救 JSR 294？

在过去的一个月中，人们对Java Modularity 工作组（ JSR 294 ）的当前状况争论不休。尽管该 JSR 使劲浑身解数来探求不同模块系统之间的共性（尤其是 Sun 的 Jigsaw 项目以及 OSGi ）, 然而目前的这些提 议都太过于复杂并且首次引入了元模块（meta-module）系统的概念。

大多数争论的焦点都聚集在语言规范及其实现的差别上。当前的情况是 JSR 294 草案（大多数专家组成员都很讨厌该草案）定义了一个元模块系统，该系统会将模块、版本、约束以及依赖的概念代理给一个“可插拔”的外部模块提供者上。但遗憾的是，这意味着版本号以及依赖之间将失去共同点，最终导致为不同模块系统所开发的模块之间很可能不兼容。

这对于 Java 社区没有任何帮助，因为人们急需一个既能与 OpenJDK jigsaw 搭配使用，同时又支持 OSGi 的模块系统。很多人都在问为什么 OpenJDK 无法重用 OSGi，答案很简单：OSGi 不仅仅只是个模块系统，尽管其核心规范（定义了模块层）内容不多，但协议问题依然阻挠着 OpenJDK 对其的重用。

相比于开发一个元模块系统（对语义以及外部提供者的概念定义都很模糊），有人在邮件列表中提出了简单模块系统的概念，建议趁早摆脱元模块系统的束缚而将精力放在这两个模块系统（Jigsaw 以及 OSGi）都能支持的共同点上。这就需要大家对模块版本的表示方式达成一致（不管怎么说，这对于 Java 开发者都是件好事），同时定义模块依赖（类似于 Maven 的模块依赖），这样在一个模块公开自己所定义的所有包时就会隐式导入所需的包。

凭借这一点，Java 开发者就能构建兼容于 Jigsaw 与 OSGi 的模块，尽管这二者都具备强大的扩展能力，但对于那些只是构建 Java 程序库并提供模块的大多数开发者来说，暂时还用不上这一点。这样提供者就无需为使用哪种格式费心了，而可以将精力集中在 Java 程序库的静态模块上。我们还可以在动态模块系统中充分体验到更加强大的动态模块；但对于绝大多数情况来说，静态模块足矣。

简单模块系统的提议主要包括如下几点：

• 简单可视化模型——如果某个模块需要另一个简单模块，那么该模块中的所有内容都将对所依赖的模块可见，并不阻止大家以跨越模块的方式来分割包。这正是目前的 Jigsaw 所做的事情，也是大多数不熟悉 OSGi 表达模型的人们所渴望的东西。它与现在基于 Maven 的构建系统以及运行时类路径模型很相像。OSGi 必须要更新其规范以为该简单可视化模型提供支持，而这非常类似于 bundle 上的 Require-Bundle（会导出所有的包）。
• 单版本号模式——单一、共享的版本号模式非常必要。该简单模块系统必须要定义一种版本号模式，而 Jigsaw 需要使用该模式，同时 OSGi 也需要转向它。该版本号模式必须要定义一种自然顺序关系以便可以通过 compareTo() 对其进行排序。当前的 OSGi 定义了一种由 4 个部分组成的版本号模式并实行自然顺序排序。Sun 已经声明 OSGi 所定义的这种模式并不满足 Jigsaw 的需求。我们必须要将这些需求收集起来以设计一种版本号机制及自然排序关系，这样简单模块系统、OSGi 以及 Jigsaw 就能对其进行共享了。OSGi 必须要更新其规范以支持该新的版本号模式。
• 模块成员——对于简单模块系统来说，编译器必须假定模块成员要符合模块的规格，比如说 JAR 文件或是目录。在运行时，每个模块都有自己独立的类装载器（关联到特定的模块上）。一个模块所加载的所有类型要由该特定的类装载器加载并成为该模块的成员。
• 没有“黑洞”——我们必须保证规范中没有“黑洞”才能让该提议的价值彰显出来，所谓黑洞，就是一旦没有特定模块系统的辅助就无法理解某些源代码。规范必须要指定简单模块系统的具体语法和语义，包括版本号、依赖表达式以及模块成员等等。Java 语言规范不允许我们定义自己的语言关键字或是操作符。对于 module-info 源文件中的模块信息和模块成员规则也要保证这样。

由于 JSR 进程工作方式的原因，一个或几个人负责编写规范，而专家组则在那儿讨论、指出问题所在或是批准草案。曾几何时，元模块系统没有通过专家组成员的批准，很多专家组成员（包括 Sun 的雇员）感觉有必要编写自己的提议以突出当前草案中存在的问题。这就像是为得到针对 Java 的标准模块系统所作的最后挣扎，大家都期望简单模块系统（整个都定义在了语言规范中，无需外部实现的支持）既能满足 OpenJDK Jigsaw 的需要，也能符合 OSGi 的需求。

或许最大的胜利就是各方在版本号的表示上达成了一致。OSGi 早就定义了 major.minor.micro.qualifier 格式，它对于所有的Java 程序库都足够了，但唯独Sun 是个例外（Sun 使用了1.major.minor.micro.qualifier 格式）。然而还有一个重大的差别：在OSGi 中空的qualifier 代表了最低的版本号，而在大多数Java 开发者的潜意识和Jigsaw 中，空的qualifier 却代表了最高的版本号（换句话说，在Jigsaw 中，1.0.0 要大于1.0.0.beta，而OSGi 则恰恰相反）。寻找一个共性来解决这个问题（将其作为一个特例）可以看作是模块系统版本号需求的一个巨大进步，哪怕是再给版本号增加一部分。OSGi 的未来版本可能会支持这一点。

对于Java 来说，用简单模块系统替换掉元数据系统，你有什么想法呢？

查看英文原文： Can the Simple Module System save JSR294?