JCP EC 投票反对 Java 平台模块系统

近日，JCP 执行委员会有关 JSR-376（Java 平台模块化系统，通常称为 Jigsaw）的投票结果在Java 社区进程页面上发布，有10 票赞成提案，13 票反对公开评审。

InfoQ 之前曾经报道过，这伴随着为期一周的激烈的公开辩论和评审，以及 Reinhold 最近针对 JCP EC 的抗辩：

当你考虑如何投票时，我劝你就事论事地评判这份规范，另外，你要考虑到，自己的投票会成为什么性质的先例。

执行委员会似乎把这话记在了心里，并在回复评论时指出，提案以其目前的形式尚未准备就绪。其中部分担忧来自于自动化模块命名，即如果没有在 Jar 文件的 module-info.class 中指定，则模块名将从文件名生成。由于文件名是不确定的，任何从文件名到显式声明的名称的切换都无法以向前兼容的方式实现，所以这个问题可能会严重地伤害 Java 社区。Stephen Colebourne 是 Joda Time 及 Java 8 时间包的作者。他早些时候写道：

自动化模块允许模块依赖于非模块。但这是通过在文件名上指定 requires 子句而不是模块名来实现的。如果模块是基于文件名发布的，那么这后续会让我们吃苦头。一条新的 MANIFEST.MF 记录允许任何开源项目选择一个模块名，并立即发布其选择。当 JPMS 看到 MANIFEST.MF 记录时，它会将该值用作自动化模块的名称。

社区成员必须不惜一切代价避免发布基于文件名的模块化 Jar 文件。但是，从现在开始，社区成员可以发布包含新 MANIFEST.MF 记录的 Jar 文件（虽然从技术上讲 MANIFEST.MF 记录尚未最终确定，但它应该很快就会定下来）。

有关自动化模块名的反馈已经在专家组邮件列表上报道过，而公开评审草案则被希望按照原样发布。然而，在过去这些天里，Reinhold 认识到自动化模块名的问题，使得邮件列表形成了一份修正提案。 不过，这并不包含在提交给 JCP EC 的公开评审草案中，成员们注意到了评论，他们不能投票支持这份使用了先前写法的提案，因为它没有包含邮件列表上讨论的最终提案：

LJC 对这份规范投了反对票，因为它是在投票开始阶段提交的。在 14 天的投票时间里，对于部分非常困难的问题，如#AutomaticModuleNames，规范负责人和专家组在达成一致方面取得了重大的进展。

不过，我们 [SAP SE] 尤其关心的是，专家组内缺少直接沟通。假如这份 JSR 未能以三分之二的多数票获得批准，我们希望专家组和规范负责人可以使用另外 30 天的时间经常见面，从而理清存在的问题，提出新的、更合理、更高瞻远瞩的提案。尽管我们知道不可能改正所有问题，但我们认为，过去的几天已经清楚地表明，良好的折中还是可能的（例如“自动化模块问题”），我们相信，多出来的时间可以用于提交一份更好的规范，供重新投票。

反馈普遍是积极的，并且认可到目前为止为实现 JPMS 所做的大量工作。由于未能获得三分之二的多数票，为了提交一份更新过的提案，公开评审阶段现在另外延长了 30 天。接下来，后续的投票可以基于根据邮件列表上的讨论修正后的提案进行，如重新讨论自动化模块命名方案。不过，它还是建议，讨论应该在邮件列表上进行，而不是博文讨论区：

最后，请所有成员和规范负责人回到谈判桌上来，彼此间直接交流，而不是在博文和公开信中互相指责！

虽说有人可能会将反对票视为反对 JPMS，但事实是，目前为止，与该 JSR 相关的工作还在进行当中，还有一些不完善的地方，在最终投票之前可以忽略。公开评审将在 30 天内再进行一次，如果公开评审发现了新问题，则可以重新评审。不过，一旦 JSR 通过了公开评审，就会进入最终评审投票阶段，不允许再重复，这是最后一次。虽然它不会影响 OpenJDK 中的实现（代码已经落地），但它会影响其他 Java 供应商为了保持和 Java 兼容所需要做的工作。Oracle 可以选择否决或解散 JCP，从而让一份尚未完成的规范快速通过评审。Martijn Verburg 在 Java 伦敦社区的博客上发文解释了 LJC 投反对票的原因：

这是 JCP 所支持的（不，不只是因为政治）

临时观察员及部分科技媒体可能会得出结论，所有这些不过是大公司政治。近期的公共博客和公开信助长了这种情绪，但是我们极力主张，人们要读一下伴随“反对票”的评论。

虽然 Oracle 是 Java 的管理者，但 JCP 执行委员会（EC）的宗旨是引导整个 Java 生态系统的发展，我们强烈的感到，它在这种情况下理应如此。

Ben Evans 是 EC 中另一位来自 LJC 的代表，他告诉 InfoQ：

自 Jigsaw 项目启动以来，LJC 一直是它的支持者。我们清楚地知道，这种根本的变化所包含的复杂性对 Java 应用程序打包和部署方式的影响。不过，更重要的是，我们第一次有了模块系统。

在过去的几个周里，尤其是从 JPMS JSR 被提交评审以后，专家组已经在解决未决问题方面取得了重大进展。然而，主要问题依然存在，需要在正式发布以前修复。最重要的是修复自动化模块的建议，因为社区已经表明，他们最感兴趣的是模块的迁移路径（尤其是，例如，基于 Maven 的应用程序）。

一旦 EG 就如何将其应用到现有代码提供了一些指引，如果获得了进一步喘息的空间，就可以举办一些骇客日活动，看看社区对新特性提案的反应。

JPMS 仍然具有很大的潜力——但在可以广泛使用之前还有更多的工作要做。

IBM 的 Tim Ellison 在有关投票的评论下发表了一篇博文，表达了希望未决问题得到解决的愿望：

专家组和规范负责人会继续密切合作，富有成效地完善规范草案，我们对此持乐观态度。我们坚信，修订可以让 JSR 376 规范的几个遗留技术问题的状况得以改善，并作为“建议的最终草案（Proposed Final Draft）”，而且不会对 Java 9 项目计划产生重大干扰。

Twitter 也发表声明，解释了他们投反对票的原因，并表达了希望规范负责人和专家组协力解决未决问题的愿望：

对于 JPMS，我们主要关注的是，它可能给 Java 开发人员带来破坏性变化，却没有达到人们对于这样一个系统的预期，提供立竿见影的效果。我们担心，这会延误这项重要技术的广泛应用。我们希望，如果 JPMS 更全面地实现原来的一些目标，它就可以解决 Java 开发人员现如今面临的真正痛点。特别是，非导出程序包名称冲突可以说不符合该 JSR“互不干扰（non-interference）”和“强封装”的目标。但是，如果模块更彻底地隔离，那么可以通过将它们作为非导出程序包隐藏在模块中，使构建系统支持同一程序包的多个副本。这种切实的、立竿见影的效果可以抵消开发人员模块化自己的源代码所需要完成的所有困难工作，可以促进 JPMS 更快的应用。

出于上述原因，Twitter 对 JSR 376 投了反对票。我们希望，规范负责人和专家组在接下来的几个周里协力消除我们的担忧，并解决其他投反对票的 JCP 执行委员会成员提出的其他问题。我们期待着在 JSR 376 再审投票时可以投赞成票。

InfoQ 已经和 Mark Reinhold 取得联系，请他对此事发表评论。在收到回复后，我们会在这里发布。

查看英文原文： JCP EC Votes Against the Java Platform Module System