Java平台模块化系统（JSR 376）通过公开测评复议投票

Java 语言开发

摘要： 在JSR-376最初公开测评投票未获通过的近两个月后，现在JCP执行委员会以压倒性多数通过了近期的复议投票。就这一最新投票结果，InfoQ采访了Java伦敦社区的联合创始人及jClarity的CEO Martijn Verburg和IBM资深技术人员Tim Ellison。

作者： Michael Redlich

正文：

Java平台模块化系统（JPMS，Java Platform Module System）亦称为Jigsaw项目或JSR 376。尽管在两个月前JPMS未通过最初的公开评测投票（Public Review Ballot），但是这次Java标准制定组织（JCP，Java Community Process）执行委员会（EC，Executive Committee）以压倒性多数通过了复议投票。InfoQ在前期曾报道过，有一系列的原因导致EC成员IBM和RedHat在首次公开评测投票前就公开宣称将会投反对票，并在报道中推测Twitter和Java伦敦社区最终也将会投反对票。

在复议投票中，除Red Hat以外的所有EC成员都投了赞成票。Red Hat在投票中弃权。Red hat对自己的投票原因做出了如下解释：

Red Hat此次投了弃权票，尽管我们认为自上次投票以来为在EG内达成一致已经取得了积极的进展，我们也相信那些影响当前建议被社区更广泛采纳的条目是可以在发布的30日扩展期内得以解决的。虽然如此，我们并非想要拖延Java 9的发布，并很高兴看到有规范牵头人和EG对随后的Java版本提出了更积极的规划建议，因为理解未来更改是否需要并将会在哪里发生，关键是获得在模块化系统上的真实世界反馈。我们希望项目领导者和EG会继续对来自于更广泛Java社区的输入保持开放态度，就像过去30天中所做的那样，并期待由来自于OpenJDK之外的用户和社区数据所驱动的Java演化。

Twitter在首轮投票中投了反对票，但在复议投票中改投了赞成票。Twitter的JVM/GC工程师Tony Printezis在博客中给出了如下解释：

JSR 376专家组（EG，Expert Group）已经努力澄清了一些模糊之处（#RestrictedKeywords、#CompilationWithConcealedPackages和#ResolutionAtCompileTime），并在修订的JSR 376规范中做了一些重要改进（#ModuleNameInManifest）及放松了强封装。

考虑到上述工作，我们决定对JSR 376公开测评复议投票投赞成票。

通过去除了一个重要的障碍，放松的强封装默认会有助于JDK 9的采纳，至少在短期内会是如此。考虑到这些改进，当前在EG内基本一致地认为，JPMS已准备好在JDK 9中发布。

伦敦Java社区在首轮投票中也投了反对票，并在复议投票中改为赞成。就这一最新投票结果，Java伦敦社区的联合创始人及jClarity的CEO Martijn Verburg，以及IBM资深技术人员Tim Ellison接受了InfoQ的采访。

InfoQ：你们如何看待Red Hat选择投弃权票？

Verburg： 首先要声明，这是我个人的看法和猜测。我认为Red Hat之所以这样投票，是因为它认为投赞成票将会让它的客户产生错觉，认为当前形式的Jigsaw已准备好提供所有用户的全部用例使用。Red Hat清楚地表明了自己的态度，即虽然当前形式的Jigsaw是一个可接受的基础，但是尚未对所有用户和用例准备好。

Red Hat正寻求解决的一些Jigsaw条目，已经推迟到稍后的日期。我们当前仍不确定对这些问题的解决是否将会出现在Java 9的更新版发布或是Java 10中。

InfoQ：自5月8日投票后，还做了哪些更改？?

Verburg： 非常多！详细技术细节记录于如下会议记录中：

• 2017年5月18日专家组会议记录；
• 2017年5月22日专家组会议记录；
• 2017年5月23日专家组会议记录。

其中需要特别强调指出的是：

• 在版本命名格式上取得了一致。
• 在自动模块命名（Automatic Module Naming）规则上取得了一致，并给出了最佳使用指南（这对Maven生态系统非常重要）。
• 同一模块的多版本处理问题将会延期解决。
• 在将放宽强封装作为默认上取得了一致（这意味着更少的应用将会打破常规，而是给出告警）。
• 整理了部分关键字的使用方法（支持Eclipse编译器工作）。T

InfoQ：为使JSR-376投票通过，是否还实现了一些其它的改进和贡献因素？

Verburg：事实上，规范牵头人和EG间通过电话会议联系，并为改进相互之间的通信和协作而做了大量的工作，这是尤其至关重要的。

Ellison：在5月8日投票关闭后，还完成了一系列的改进^【1】。其中部分改进是一些相对较小的API改进，这些改进早就应该完成，即便规范那时已经进展到建议最终草案（Proposed Final Draft）状态。其它的一些改进是提供了新的功能，包括支持已有代码更容易的迁移，以及支持Java 9概念在已有软件库和应用中更宽泛的采纳。作为专家组，我们聚在一起（虚拟的）并探讨了一些突出的问题，决定了哪些问题应在最初版本中“必须解决”，哪些问题可以推迟到稍后的Java SE版本中，以及哪些问题应该在当前阶段被抛弃。

对于通过增加平台发布节奏而确保提升Java SE技术的生命力和步伐的做法，在JCP中存在着一些讨论。这必须实现于多年来一直对Java工作良好的标准化过程中，并且具有一个能为商业利益提供富有成效协作的论坛。

综合这两个方面的因素，我希望有JSR维护版本专家组能尽快重新考虑一些被推迟的JPMS条目。而且通过提交一个最初版本，任何更进一步的提升将会受益于一些真实世界经历。

对于这个话题，我在一篇博客文章^【2】中做了详解介绍。其中的突出问题列出于文档^【3】中。

[1] https://www.jcp.org/en/jsr/results?id=5959

[2] https://developer.ibm.com/javasdk/2017/05/26/building-consensus-jsr-376-java-platform-module-system/

[3] http://openjdk.java.net/projects/jigsaw/spec/issues/

InfoQ：你们希望在JSR-376中能看到哪些更进一步的改进？

Verburg：我希望能有更多的工作围绕着版本控制和版本支持开展。当前，挑出问题的责任依然落在构建工具上，但我们希望Jigsaw能对此提供强大的引导作用。

Ellison：模块化并非一次性设计。我们认为它将随人们的使用而不断进化，给出我们以前从未看到过的问题，我们从来没有预先考虑到的用例，并不断地采纳业界的改进（例如云、微服务、无服务器等）。我一直关注着如何与社区共同工作，如何了解我们客户的利益，意在确保当前代码并未落后于Java SE的演化，并且很好地支持新的框架和编程模型。

查看英文原文： Java Module Platform System (JSR 376) Passes the Public Review Reconsideration Ballot