Java EE 6的依赖注入终于达成一致了

guoln

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