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： 非常多！详细技术细节记录于如下会议记录中：
其中需要特别强调指出的是：
- 在版本命名格式上取得了一致。
- 在自动模块命名（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/
InfoQ：你们希望在 JSR-376 中能看到哪些更进一步的改进？
Verburg：我希望能有更多的工作围绕着版本控制和版本支持开展。当前，挑出问题的责任依然落在构建工具上，但我们希望 Jigsaw 能对此提供强大的引导作用。
Ellison：模块化并非一次性设计。我们认为它将随人们的使用而不断进化，给出我们以前从未看到过的问题，我们从来没有预先考虑到的用例，并不断地采纳业界的改进（例如云、微服务、无服务器等）。我一直关注着如何与社区共同工作，如何了解我们客户的利益，意在确保当前代码并未落后于 Java SE 的演化，并且很好地支持新的框架和编程模型。
查看英文原文： Java Module Platform System (JSR 376) Passes the Public Review Reconsideration Ballot
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论