InfoQ过JSR 376（Java平台模块系统）的开发现状，它通常被称为“Jigsaw项目”。现在，有一件不太寻常事情，IBM和Red Hat都公开表示，将会对Jigsaw目前的状态投反对票。\

这个项目试图为Java提供一个标准化的模块系统，它最初的计划是在Java 7中实现，在Mark Reinhold之后，转移到了Java 8中。2012年7月，Oracle再一次推迟了这个项目，将其中。即便如此，这个项目依然，这主要是因为Jigsaw的复杂性而且它需要进行广泛的测试。\

Jigsaw的范围是非常广泛的，它不仅想要模块化庞大的Java运行时，还想强制进行强封装，这样的话Java代码只能通过公开的接口去访问平台库。模块化的代码不能随心所欲地进入另外一个模块的内部。\

不仅如此，Oracle希望模块系统不仅用在JDK本身中，还要用在应用程序的代码中。为了实现这一点，JSR 376专家组（Expert Group，EG）曾经讨论过应用级别模块化与JDK模块化的各个方面。\

除了标准流程之外，目前已经有两个主要的模块实现，它们与Jigsaw的范围有些重叠，这两个方案就是JBoss Modules和OSGi，前者来自Red Hat，而后者由一个厂商所组成的联盟来管理，这些厂商中包含IBM。\

Red Hat和IBM都是Java Community Process执行委员会的成员，这个委员会有25个成员，它们要负责批准所有的Java新标准，包括“平台释放版本”要包含哪些的内容，比如Java的主版本。这样的释放版本必须要取得三分之二席位的支持。\

来自IBM的Tim Ellison在OpenJDK邮件列表中，他这样评论到：\

\

IBM也会投反对票，这反应了我们对这个JSR的态度，我们认为眼下它还没有超出Public Review阶段的要求，并不适合继续推进到Proposed Final Draft阶段。\

JSR 376专家组和公众已经针对规范当前的public review草案提出了很多合理的问题和关切，这些问题应该进行进一步的讨论并得到妥善解决。我们倡导专家组的所有成员继续协同工作，解决邮件列表中所记录的问题。\

在将规范推至下一阶段之前，IBM希望在整个专家组中形成更紧密的共识。

Ellison的表态似乎是对一个私下交流的回应，这个交流是在Ellison、Mark Reinhold和Scott Stark（Red Hat）之间进行的，Stark是这样评论的：\

\

目前，Red Hat将不会投票批准JPMS的public review草案，因为它并不能实现Java社区的最佳利益。

有个问题在于IBM和Red Hat所提供的已有的模块系统很难与Jigsaw便捷地进行互操作。不过，这两个系统都没有在市场上占据支配性的地位，尽管被影响者会比较痛苦，但是大多数的Java项目并不会受到这种不兼容性的影响。\

但是，Jigsaw的问题并不局限于OSGi和JBoss modules。在Java世界中，主流的代码打包和分发系统是Maven，Jigsaw并没有为基于Maven的项目提供一个清晰的升级路径，Maven会将代码打包到JAR文件中，Jigsaw并没有提供将其打包到模块中的升级途径。\

这种关切在一篇中进行了详细描述，这篇文档是由Red Hat和外部的Maven专家共同编写的。Maven的核心关注点是所谓的“自动化模块（Automatic Modules）”，对社区中的很多人来说，Maven所关注的情况要比与各厂商的模块系统间的兼容性问题要严重得多。\

Martijn Verburg是伦敦Java社区的领导者（同时也是JCP执行委员的投票成员），他这样告诉InfoQ：\

\

作为EC成员，这么早就阐明其投票立场并且采用如此公开的方式，实在有些不同寻常。这表明，在Java生态系统中，主要的参与者对JPMS和Jigsaw这一实际实现有着很严重的担忧。尽管目前的模块规范和实现为Java带来了许多重要的安全和简洁（compact）运行时提升，但是它（还）没有弥合与其他通用模块系统的鸿沟，也没有处理好它们所依赖的构建工具，无论正确与否，Java平台恐怕会经历Python2/3这样的分裂。

在Java新版本的开发周期中，临近结束时，出现如此明显的分歧甚至敌视是前所未有的。尽管这只是一个Public Review投票，而不是最终批准投票，但这是一个明确的警告信号。\

如果考虑到其他厂商和社区的观点，Oracle对Java 9的交付时间点似乎会出现冲突。到底Oracle会改变方向（这样的话，有可能会造成Java 9的再次延期）还是坚持自己的观点（即便主要的厂商和社区参与者有反对意见），尚有待继续观察。\

查看英文原文：