Google和Spring 提议一个JSR来标准化一组与依赖注入相关的注解。有几个人要求我对这个以及它与JSR-299的关系进行评论。
首先，提议的JSR将定义一个比299中已有的功能更严格的部分，因此299容器支持提议的注解不会存在困难。当然，299的任何实现都有一些功能远远超出了这里所提议的内容。因此，这个新的JSR提议并不与299竞争。
其次，这个JSR提议中的注解在某种程度上等同于299中定义的注解的子集，除了命名外
- @Qualifier相当于@BindingType,
- @Scope相当于@ScopeType,
- @Singleton相当于@ApplicationScoped,
- @Named只是一个内置的绑定类型，而
- 的Provider<X>接口相当于Instance<X>.
此外，
- @Inject在某种程度上类似于@Initializer.
现在，我认为引入一组与299中那些语义上相同且针对完全相同问题的注解将是一个巨大的错误。因此，我将这个JSR提议理解为：让我们取299中已定义的注解的子集，将其拆分到不同的包中，并使它们可被其他依赖注入容器使用。这当然是可以做到的，在某些程度上也很吸引人，但我还在等待被说服这真的值得去做。
问题在于新的JSR提案已经仔细地界定范围，只包括JSR提案者（即Spring和Guice）已经达成共识的内容，并排除了现有依赖注入解决方案之间所有可能的分歧区域。这就像提议JSR的人意识到他们无法就所有困难的问题达成一致，并希望继续以他们自己不兼容的专有方式处理这些问题。
例如，该提案排除了以下有趣的问题范围
- 我如何与依赖注入容器交互？
- 哪些类型的对象是可注入的？
- 我如何向容器指示某个对象是可注入的，并声明其限定符？
- 注入对象的生命周期是什么？
- 我如何定义不同的部署场景，以及不同注入类型的实现？
- 在存在循环依赖、序列化作用域等情况时有哪些限制？
- 存在哪些SPI来允许第三方框架与容器集成？
- 在Web环境中存在哪些标准的范围集？
（这绝对不是一份详尽的列表。）
但从应用程序开发人员的角度来看，如果没有一个针对所有这些问题的规范，就无法使用这些注解构建可移植的应用程序。而可移植性不正是JSR的通常目标吗？
相比之下，JSR-299确实明确了所有这些内容，以及更多：它是对依赖注入容器和在这些容器上运行的便携式应用程序的完整规范。在我看来，这要更有用。
（更新以纠正对提供者接口的解释。）
