今年初， 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 的一部分。迄今为止，社区的反响还是积极的（ Matt Corey 、 Jeremy Norris 、 Alex Miller 、 Oliver Gierki 、 Niklas Gustavsson ）。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
字节跳动日志智能化的探索与实践
合创汽车卡片式代码配置平台探索与实践
后疫情时代，SaaS 产品建设思路及实践
评论