新的java ee 6规范，在七月16日被认可。选票结果以压倒性的优势通过：14票赞成，1票反对（apache），1票弃权（borland）。jsr并没有非常出色的通过，自apache软件基金会发表的公开信和在tck用户约束所带来的问题以来，这是第一个主要的jsr被认可。jsr虽然通过了，但是承受来自ibm对许可证模式要求的压力，同时还有来自red hat 和 intel 的预期要求。

    ibm投了赞成的一票，它的评论是：

    ibm之所以投了赞成一票是看在它的技术水平上，如果从许可证的条款来看，我们是不会投赞成票的。ibm只支持这样的许可证模式，这种模式有利于创造一个开放的环境，让第三方能够独立的实现java的规范，而不允许个人或者公司为了个人的利益行使一些不必要的限制。我们支持开源许可证模式，为jcp做出自己的贡献，和希望其它的公司能够支持这种趋势。这种评论没有直接针对jsr目前的业务和许可证模式，但是，评论反映出ibm自己更为喜欢的许可证模式。

    intel也做了一个类似的评论：

    规范制作小组声称实现这些jsr并不存在使用限制，这是好的。apatch关于java se的公开信（http://www.apache.org/jcp/sunopenletter.html）声称测试jcp兼容性的许可证不应该用来限制或者约束更富有竞争、更具兼容性的实现；具有约束的许可证不能满足jspa发展需求的。我们同意这个观点，对于每一个jcp投票，我们将会询问规范制作小组是否把这些约束加入到许可证中去了。

    red hat虽然投了赞成票，但是同时做了一下评论：

    规范制作小组证实ee6 tck不包含使用约束，正如apatch先前对另一个jsr所提出的要求。没有用户约束是一件好事情。
但是，在没有清晰的jspa规则的情况下，到底有没有约束我们也不得而知，我们仍旧担心老问题有会重新浮出水面，任何jsr都会存在这种可能性。 

    apache投了反对的一票，给出的原因如下：

    apache软件基金会没有投赞成票是因为规范制作小组违背了jspa的原则，详细见http://www.apache.org/jcp/sunopenletter.html ，因此如果以前的问题还没有解决的话，我们是不同意开始另外一个jsr的。这个投票结果并不是对jsr的技术水平的否定。如果不是规范小组的问题的话，apache软件基金会可能会投赞成的一票。