今年终，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的一局部。
