今年初，Google Guice和SpringSource宣布将合作提出一套标准的用于依赖注入的注解，即JSR-330。但这些注解与JSR-299却并不一致，随后引发了众多的争论，不过现在一切都已经尘埃落定：JSR-299采用了JSR-330的注解，两者都将成为Java EE 6的一部分。
　　有不少人针对JSR-299与JSR-330的冲突谈到了自己的一些看法，列举如下：
　　Gavin King：我认为引入另一套语义上与299相同的注解完全是个错误，而且其尝试解决的问题也与299大同小异。
　　Bob Lee：虽然299对于那些小型的Java EE应用来说很适合，但其全局配置以及不直接的天性使之很难适应于数百万代码行的应用，就像Google所开发的。我们能够在Guice上轻松支持299 风格的注解，但却无法通过299实现Guice的全部功能，因此没有理由放弃Guice而转向299。就我个人来说，我认为你们在299上已经进行了不少的创新，但却没有完全理解用户代码是需要维护的这个事实。
　　Alex Miller：向JSR 299领域进军是个危险的信号。
　　Antonio Goncalves：我希望我们不要打响一个新的战役，就像Java Module(JSR 277)和Modularity Support(JSR 294)之间那样。
　　Rickard Öberg说出了反对意见：相对于泛泛的使用@Inject这样的注解，我们选择使用能代表目标对象范围的注解，因为什么都是也意味着什么都不是。
　　JSR-330已经通过了JSR评审的投票，但众多投票者都强调了两个规范的和谐相处：
　　Sun：我们希望该JSR能与JSR-299共同努力以便为SE和EE平台达成一个一致、全面的依赖注入标准。这个标准务必先于该JSR的公共预览版发布前形成。
　　Red Hat：我们认识到该草案是有社区支持的，因此打算在专家组发布公共草案时再发表最终意见。如果该JSR与JSR-299之间能达成某种一致(这种一致性会为依赖注入定义一种轻量级的模型)，那我们会毫不犹豫地投出赞成票。Red Hat承诺会为这种一致性贡献自己的一份绵薄之力。
　　Ericsson：我们支持为标准化Java SE的依赖注入所付出的努力，但更想强调的是保持与JSR 299的一致性对于Java SE和EE都是非常重要的。
　　IBM：我们也认为这样一份描述SE应用的依赖注入规范是很有必要的，然而所提出的注入模式却与EE平台中的定义有出入。SE/EE的注入模型必须要形成一个单独可扩展的编程模型：为SE定义一套核心功能并通过EE的功能对其进行扩展。因此，要是不统一的话，IBM是不会支持JSR 299或是330的。
　　Oracle：虽然支持该JSR，但Oracle严重关注该草案的完整性及其与JSR 299的分歧，因为这可能会导致平台的分裂。因此，我们期望在该JSR的公共预览版发布前能与JSR 299达成一致。我们相信JSR 250的一个修订或是维护版会比较适合发布依赖注入相关的注解。最终我们希望这种一致性的努力会让SE和EE平台的依赖注入保持一致，形成一个标准化的机制以满足各种需求。
　　目前这些规范之间的冲突已经得到解决。JSR-330(面向Java的依赖注入)以及JSR-299(面向Java EE平台的上下文与依赖注入)已经达成一致了，后者将采取前者的注解，两者都将成为Java EE6的一部分。

　　编辑特别推荐:

　　指点一下：到底该不该去考JAVA认证?

　　Java认证权威问答精华集