Google Guice和SpringSource宣布将合作提出
套标准
用于依赖注入注解即JSR-330
但这些注解和JSR-299却并不致随后引发 了众多争论不过现在切都已经尘埃落定:JSR-299采用了JSR-330注解两者都将成为Java EE 6部分有不少人针对JSR-299和JSR-330
冲突谈到了自己些看法列举如下:套语义上和299相同注解完全是个
而且其尝试解决问题也和299大同小异Java EE应 用来说很适合但其全局配置以及不直接天性使的很难适应于数百万代码行应用就像Google所开发我们能够在Guice上轻松支持299 风格注解但却无法通过299实现Guice全部功能因此没有理由放弃Guice而转向299就我个人来说我认为你们在299上已经进行了不少 创新但却没有完全理解用户代码是需要维护这个事实
信号个新战役就像Java Module(JSR 277)和Modularity Support(JSR 294)的间那样使用@Inject这样注解我们选择使用能代表目标对象范围注解
什么都是也意味着什么都不是投票但众多投票者都强调了两个规范标准和谐相处:- 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部分迄今为止社区反响还是积极(Matt Corey、Jeremy Norris、Alex Miller、Oliver Gierki、Niklas Gustavsson)
最新评论