最近 Java JSR 经核准通过，但 Apache 全部投了反对票。Google 与 Tim Peierls 则对 Java SE 7 与 Java SE 8 JSR 投了反对票，以此在闹得沸沸扬扬的 TCK 许可与使用限制这个问题上发出了自己的声音。
- Project Coin， JSR 334 ，13 票通过，1 票反对，1 票弃权
- Project Lambda， JSR 335 ，13 票通过，1 票反对，1 票弃权
- Java SE 7， JSR 336 ，12 票通过，3 票反对
- Java SE 8， JSR 337 ，12 票通过，3 票反对
相关的评论很有趣：Steven Colebourne 在一个网页上总结了相关公司的评论。虽说大多数都对 TCK 投了赞成票，但相关的评论却对其许可问题提出了批评：
- Google：投了反对票，因为其许可条款
- SAP AG：虽然我们相信 Java 7 的继续发展很重要，但我们想对 Oracle 就 Apache TCK 的决定表达自己的不同观点
- Eclipse：对围绕着 Java 许可的纷纷扰扰感到非常失望
- RedHat：对许可条款感到极度失望，规范领导并没有采取更加开放的许可
- Credit Suisse：目前，围绕着许可条款的明争暗斗揭示出 Java 始终没有形成一个开放的标准
众多的评论还表明只要 JSR 能让 Java 平台从现在停滞的状态向前迈进，那么这些公司就会投 JSR 的赞成票。此外，模块化在 Java SE 7 与 Java SE 8 的讨论中也被多次提到，Java SE 8 JSR 还特别提到了 OSGi 的互操作性。
这也是各大公司首次通过投票表决的方式来核准 Java SE JSR。同时，最近 Project Coin 与 Project Lambda 上的工作取得了很大的进展，Java SE 7 中的其他内容（比如 JDBC 4.1）也深受人们欢迎，Java SE 8 JSR 还包含了大量处于襁褓中的 JSR。或许当 Java SE 8 发布时，Oracle 会说这是大多数人的意愿，即便 Java SE 8 的内容与之前的版本有很大差别。
然而，由于许可问题并未得到解决，因此一些人称 JCP“仅仅是一些客户而已”——Oracle 不再认真对待 JCP 了。这场争斗最后的结果就是 Apache 宣布离开 JCP，将继续追寻自己的脚步。这也许是 Apache 软件基金会最后一次对 JSR 投票了：
Apache 软件基金会必须对 JSR 投反对票。虽然我们支持 JSR 的技术内容，也认为 Java 平台需要向前发展，但凭良心说，我们得对这个 JSR 投反对票，原因在于：
- 该 JSR 的 TCK 许可包含了一个“使用限制”，限制了独立实现的正常使用，这个许可元素不仅被 JSPA 所禁止，还被 JCP EC 的大多数成员所拒绝——包括 Oracle。我们只能推测 Oracle 包含这一限制的原因，但我们认为开放的规范生态系统必须要独立于任何组织的商业利益。
- 该 JSR 与自己的 TCK 许可自相矛盾。JSR 显式声明 Java SE 以嵌入式部署作为目标。但 TCK 许可则特别明确地禁止了经过测试的独立实现的使用（比如说上网本）。我们认为这会对潜在的实现者造成误导，通过 TCK 的任何独立实现都应该可以使用并且根据实现者所提供的条款进行分发。
- 规范领导忽视了多个 EC 成员的再三请求
- 规范领导——Oracle——违背了身处 JSPA 的义务——为 Apache Harmony 提供 TCK 许可，让 Apache 根据自己的选择分发其独立实现。我们认为故意不履行 JSPA 义务的任何人都没资格成为 JCP 的成员。这个原则适用于所有人。
虽然我们理解 Oracle 最初的意图是不管 EC 的决定是什么都要推进 Java 不断前进，但我们还是奉劝 Oracle 尽快解决上面提到的那些问题，然后在 JCP 的体系下继续与 JCP 成员并肩作战让 Java 活力重现。
由于 Oracle 并不遵守协议，因此 Apache 软件基金会也发表了自己的声明。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论