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

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

作者 Geoffrey Wiseman 译者 张龙 发布于 2009年8月23日 上午10时13分

今年初,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 CoreyJeremy NorrisAlex MillerOliver GierkiNiklas Gustavsson )。

查看英文原文: Dependency Injection harmonized for Java EE 6

转自:http://www.infoq.com/cn/news/2009/08/dependency-injection-javaee6

javaee 6 规范 chm版本 第1章 引言 1.1 感谢 1.2 版本1.3的感谢 1.3 版本1.4的感谢 1.4 版本5的感谢 1.5 版本6的感谢 第2章 平台概述 2.1 体系结构 2.2 Profile(自定义规范) 2.3 应用程序组件 2.4 容器 2.5 资源适配器 2.6 数据库 2.7 Java EE标准服务 2.8 互用性 2.9 产品标准的灵活性 2.10 Java EE产品的扩展 2.11 平台角色 2.12 平台协议 2.13 J2EE 1.3中的变化 2.14 J2EE 1.4中的变化 2.15 Java EE 5中的变化 第3章 安全 3.1 简介 3.2 一个简单的例子 3.3 安全体系结构 3.4 用户验证的必要条件 3.5 授权条件 3.6 部署标准 3.7 未来的方向 第4章 事务管理 4.1 概述 4.2 标准 4.3 事务的互用性 4.4 本地事务优化 4.5连接共享 4.6 JDBC和JMS部署问题 4.7 双相提交支持 4.8 系统管理工具 第5章 资源,命名和注入 5.1 概述 5.2 JNDI命名上下文环境 5.3 Java EE平台角色的职责 5.4 简单环境入口 5.5 Enterprise JavaBeansTM 5.6 Web服务的引用 5.7 资源管理器连接工厂的引用 5.8 资源环境的引用 5.9 消息目的地的引用 5.10 用户事务的引用 5.11 事务同步注册表的引用 5.12 ORB的引用 5.13 引用持久化单元 5.14 持久化上下文的引用 5.15 应用程序名称和模块名称 5.16 检验器和检验器工厂的引用 5.17 数据源资源定义 5.18 引用受管理的Bean 5.19 Bean管理器的引用 5.20 支持依赖注入(JSR-330) 第6章 应用程序编程接口 6.1 必须的API 6.2 Java平台Java SE标准 6.3企业级JavaBeansTM 3.1标准 6.4 Servlet 3.0标准 6.5 JavaServer PagesTM标准 6.6 Expression Language标准 6.7 JavaTM Message Service 6.8 JavaTM Transaction API 6.9 JavaMailTM 1.4标准 6.10 Java 连接器体系结构标准 6.11 Java EE Web服务1.3标准 6.12 JAX-RPC 1.1标准 6.13 JAX-WS 2.2 标准 6.14 JAX-RS 1.1标准 6.15 JAXB 2.2 标准 6.16 JAXR 1.0 标准 6.17 API 1.1标准 6.18 API 1.2 标准 6.19 JACC 1.4 标准 6.20 JASPIC 1.0 标准 6.21 JSR-45 标准 6.22 SJSTL 1.2 标准 6.23 Web Services 2.1 标准 6.24 JavaServer 2.0 标准 6.25 Java平台公共注解1.1标准 6.26 Persistence API 2.0 6.27 Bean Validation 1.0 6.28 Managed Beans 1.0 标准 6.29 Interceptors 1.1 标准 6.30 Contexts Dependency 6.31 Dependency Injection 第7章 互用性 7.1 互用性介绍 7.2 互用性协议 第8章 应用程序组装者和部署 8.1 应用程序部署的生命周期 8.2 库的支持 8.3 类加载标准 8.4 应用程序组装 8.5 部署 8.6 应用程序的XML Schema 8.7 Java EE XML Schema定义 第9章 Profile 9.1 简介 9.2 定义Profile 9.3 Profile的总体原则 9.4 标准的扩展 9.5 所有Java EE Profile标准 9.6 Java EE Profile可选特性 9.7 完整的Java EE产品标准 第10章 应用程序客户端 10.1 概述 10.2 安全 10.3 事务 10.4 资源,命名和注入 10.5 应用程序编程接口 10.6 打包和部署 10.7 程序客户端的XML Schema 第11章 服务供应商接 11.1 JavaTM EE连接器体系结构 11.2 容器Java服务提供方协议 11.3 JavaTM事务API 11.4 JavaTM持久化 11.5 XML Web服务提供的API 11.6 JavaMailTM 第12章 兼容性和迁移 12.1 兼容性 12.1 迁移 第13章 未来的方向 13.1 JNLP(Java Web Start) 13.2 Java EE SPI 附录 附录A 早期版本的部署描述符 附录B 修订历史 科瑞网酷
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值