jcp jsr_对JSR 376表示反对：欧盟委员会尚未批准公共审核投票

jcp jsr

所有23个组织和个人成员的代表均在接受JSR 376的公众投票投票中进行了投票。当时有13票反对，10票赞成 -因此，欧共体未批准该投票。

JSR＃376公众评审投票的最终结果 ：

资料来源：Java社区流程-JSR＃376的公众评审投票

根据表决日志， IBM对否发表了以下评论：

IBM的投票反映了我们的立场，即JSR目前尚未准备好超越公开审查阶段并进入提议的最终草案。 JSR 376专家组和公众已经对规范的当前公众评审草案提出了许多合理的问题和关切，值得进一步讨论和解决。 我们提倡专家组所有成员之间继续开展工作，以解决邮件列表中记录的问题。 在本规范进入下一步之前，IBM希望在整个专家组中达成更紧密的共识。

凯尔·沃纳（Keil Werner）承认IBM和其他公司的担忧，并声称“他们的大多数担忧仍未得到EG或Spec Leads的回答，这在目前还没有使这个JSR做好准备。”

Hazelcast ， 最近告诉JAXenter ，他们将不支持该草案，并投票反对，并发表以下评论：

从我们的角度来看，专家组内部缺乏共识是一个危险的信号，要么不是所有问题都已阐明其必须采用的方式，要么某些问题已从单一角度被标记为解决。 总体而言，我们承认，该州在过去几个月中取得了长足进步，社区解决了许多问题，但似乎该州进行公众投票的权利尚不正确。
另外，流行的构建工具的问题似乎不是一个好的开始。 我们对EC的理解是，工作的一部分是防止Java生态系统受到损害，在当前状态下，JSR376不能被视为已经做好了准备。

红帽中间件团队在投票开始之前公开提到了他们的担忧，但补充说，不投票是“正确的行动方针”。

在对EG列表的先前投票和评论中，我们表达了以下观点：从中间件/ SE开发人员的角度来看，我们认为Jigsaw并没有实现其最初的目标，即成为可被Java EE之类使用的模块系统。 我们了解到，从一开始，EG的最初目标就发生了变化，试图将其重点放在仅用于对JVM进行模块化的模块系统上，这导致了一些体系结构和实现方法，这使其很难成为模块系统由SE和EE开发人员使用。 不幸的是，在EG的整个生命周期中，目标似乎都转回到尝试使其成为Java开发人员的模块系统，但是以前的实现决策似乎没有被重新考虑或无法更改，因此，人们对Jigsaw的期望很高尚未实现。 因此，我们担心当前的实现对更广泛的Java社区的影响，尤其是现有项目和产品（包括Java EE以及其他方面）的影响。 我们在EG列表中提出了几个问题，试图以我们认为是微创的方式纠正其中的一些问题，但遭到了拒绝。 此外，我们认为，对于JVM如此巨大的一系列变化，EG尚无足够的共识，这可能对Java社区产生同等巨大的影响，并且在接收和讨论社区输入方面缺乏开放性。 我们认为，对所有输入和共识收集进行更审慎的评估应该不会花费太多时间，并且会导致整个Java生态系统更好地接受某些东西。

尽管Software AG投票否决，但他们对接下来的30天持肯定态度，可以用来“试图在EG内形成更健康的共识”。 他们还补充说，应该特别注意“模块化世界中现有软件的迁移路径，以及规范与现有已建立的Java实践和构建系统的共存（＃ModuleNameInManifest，＃CyclicDependences，＃AutomaticModuleNames，＃AvoidConcealedPackageConflicts ，#MultiModuleJARs。”

SAP SE承认“迄今为止所取得的巨大成就和出色的工作”，但是选择了否决。他们认为“尽管JPMS在Java平台本身的模块化方面处于很好的状态，但仍然存在一些问题。 Java平台之外的库和框架的粗糙边缘，应在规范最终批准之前解决并达成共识。

在开发过程中，直到现在，仍不清楚在JPMS / Jigsaw的开发过程中哪些内容被视为实现细节，以及哪些内容将成为标准规范的一部分。 诸如模块和运行时映像的二进制格式之类的功能，jlink工具以及诸如哈希和版本之类的新类属性是非标准化实现细节的示例。

但是，我们特别担心的是专家组内部缺乏直接沟通。 假设该JSR不能以所需的三分之二多数批准，我们希望专家组和规范负责人将额外的30天用于例行会议，以解决其余问题并提出新的，更多的建议。可持续发展的前瞻性提案。 尽管我们知道不可能解决所有问题，但我们认为最后的日子已经清楚地表明，仍有可能做出良好的妥协（例如，“自动模块问题”），并且我们有信心额外的时间可以用来为重议投票提交更好的规范。

最后，我们要求所有成员和规范领导回到会议桌，直接相互交流，而不必通过博客和公开信互相指责！”

伦敦Java社区回应了SAP的评论，尽管他们承认“在14天的投票期内，Spec Lead和EG在诸如#AutomaticModuleNames之类的一些非常棘手的问题上取得了巨大进展，但仍在进行中通过讨论其中的一些问题，生态系统根本没有足够的时间来足够深入地讨论某些新设计，也没有足够的时间来花费和时间基于最新规范（例如Eclipse ejc编译器或最新版本）来实现和测试原型。 Maven中的自动模块命名设计。

如果需要，我们非常期待能够在<= 30天之内对一个版本进行投票，该版本的EG（和生态系统）花费了很少的额外时间来讨论/实施/测试其中的一些版本困难的规格项目。 当然，过去14天已经表明，即使观点在相反的角落开始也可以达成共识，我们认为还需要一个很短的时间才能真正陷入最后的困境。”

Twitter，Inc.投否决票是因为他们担心“此JSR将证明对Java开发人员具有破坏性，而最终并没有提供这种系统所期望的收益。” 他们对以下事实表示关注：“这将延迟这项重要技术的大规模采用。”

我们希望，如果JPMS能够更全面地实现某些原始目标（特别是非导出包名称中的冲突可能与“非干扰”和“强封装”目标不兼容），那么它可以解决Java的真正痛点。开发人员如今已经拥有（例如，通过将它们隐藏为未导出的软件包来处理同一软件包的多个副本）。 这将鼓励更多的开发人员Swift采用模块化开发。 最后，我们认为，对于如此重要​​的JSR，JSR负责人和EG成员之间必须达成更广泛的共识。”

Tomitribe认为，投票否将间接帮助此JSR：“虽然投票否定的30天窗口期将无法达成完美的共识，但我们确实相信这将有很大帮助。 它有时间让灰尘沉降。 由于过去2周中的所有更改，最终表决的确切内容在某些方面还不清楚。”

我们看到选择30个固定的窗口来回往返EC的积极性，因为它保持着对动量至关重要的压力。 JSR-299（CDI 1.0）在其公开审核投票和最终批准投票之间进行了9个月，大大延迟了Java EE 5。 我们不想在这里看到同样的情况。 30天的窗口既适用于规范潜在客户，又适用于本质上适用于EG的专家组，他们知道我们将在此之后立即进行投票。

尽管“不投票”感觉像是拒绝，但我们最终认为这是获得JSR更大共识的最支持票，同时仍保持时间压力。

有关投票和评论的更多详细信息，请查看投票日志 。

翻译自: https://jaxenter.com/jsr-376-ballot-not-approved-133860.html

jcp jsr