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

作者 Alex Blewitt 译者 张龙 发布于 2009年9月2日

领域

过程 & 实践,

语言 & 开发

主题

JSR 294 ,

JSR 291 ,

JCP标准 ,

JCP ,

Java ,

Maven ,

语言 ,

构建系统 ,

编程 ,

社区 ,

OSGi

分享到

在过去的一个月中，人们对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?

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

1. 返回顶部

   版本号的理解

   发表人 liu rick

   1.0.0是大于1.0.0.beta ，还是小于1.0.0.beta？还真是个问题

   回复