最近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活力重现。