jsr规范在哪查看_剑仍悬在拼图的头上：JSR 376的公众评审投票今天结束

jsr规范在哪查看

组织和个人成员的所有23位代表在接受JSR 376的“公共审核投票”中进行了投票，现在决定日终于到了。 正如JAXenter在5月初所写的那样，Java社区流程执行委员会的成员在投票前公开宣布其决定是非常罕见的。 对于他们来说，在比赛中这么晚说出来甚至更为不寻常。

Java平台模块系统JSR 376的规范负责人Mark Reinhold 向JCP执行委员会致了公开信，试图清除空气。

该JSR的当前规范是否完善？ 不，当然不是。 但是，它确实反映了多年的开发，测试和完善，并得到了许多开发人员的积极反馈。

如果我们花更多时间在规范上，可以使它更好吗？ 是的，我们当然可以。 我们现在所拥有的解决方案并不能解决开发人员面临的每一个与模块性相关的实际问题，但是它可以满足商定的目标和要求，并且是未来工作的坚实基础 。

我们是否应该通过追求一个不同的目标（可能会导致设计过于庞大和复杂以至于没有工作的开发人员使用它）以达到一个“更紧密的共识”，从而（可能要持续数年） 进一步推迟该JSR ？ 我看不出这怎么可能符合Java社区的最大利益。

还请参见： 开枪：IBM和Red Hat对Jigsaw项目投票“否”，可能会导致Java 9的延迟

别有用心

尽管Red Hat Middleware决定投票否决并不令人惊讶（Reinhold假定“他们追求这个替代目标是为了保留和保护他们自己开发的非标准模块系统，在JBoss / Wildfly之外很少使用生态系统”），IBM的立场是因为他们说过“在此JSR过程中很少”。

IBM的最新立场似乎植根于EG成员之间对“更紧密共识”的含糊渴望。 我也希望有更多的共识，但是鉴于Red Hat Middleware的立场，这是不可能的。 我只能得出结论，IBM决定通过延迟此JSR以及 JSR 379（Java SE 9） 来最好地满足他们的利益， 这是令人遗憾的。

广泛共识-不和谐的苹果？

Reinhold认为“ 由于EG中缺乏共识而对JSR进行投票是对Java Community Process本身的投票”，并强调指出，该流程赋予Specification Lead的原因是“广泛的决策权是为了防止EG成员阻碍进度。为了捍卫自己的狭interests利益 。” 简而言之，该流程“不要求达成共识”。

还请参见： Java 9的决策日即将来临：其他几位JCP执行成员将投票“否”

IBM的蒂姆·埃里森（Tim Ellison） 解释了为何科技巨头决定投票“不”。 几天后，他写道

只有当EG达成了我们已经准备好达成的广泛共识时，我们才应该进入拟议的最终草案，并且该决定应基于规范的优点。 多个EG成员表示我们还没有准备好。

尽管埃里森（Ellison）承认“并不是所有反对意见都能得到大家的满意解决，但他希望就如何向前发展达成共识，尤其是在EG反对意见是这样的决定可能对Java社区有害的情况下。”

这些建议要求获得2/3的多数通过。 IBM和Red Hat 并不只是在公开意见上存在分歧，并且Java 9的另一次推迟也不应该被排除在外。

Red Hat的Scott Stark发表了一封公开信，详细介绍了Red Hat和Maven开发人员对Project Jigsaw的反对意见，他对此表示担心，“可能会有两个Java软件开发世界：Jigsaw世界和“其他一切”世界。” 毕竟他的预测可能是正确的。

翻译自: https://jaxenter.com/public-review-ballot-results-jigsaw-133836.html

jsr规范在哪查看