Spring 3.1发布GA版本了

2012 年 1 月 15 日

SpringSource 在上个月中旬发布了Spring 3.1 的GA 版本。通过 InfoQ 先前的一篇文章,我们了解了 Spring 3.1 主要的新功能,其中包括对 Java 7 的支持,还有环境抽象和缓存抽象。

Chris Beams 是 Spring 框架的主要提交者,InfoQ 就 Spring 3.1 发布的更多细节和 Spring 3.2 的计划对他进行了采访。

InfoQ:Spring 3.1 原计划是在 2011 年 6 月底发布 GA 版本。为什么会推迟到现在呢?

我们原计划要为 Spring 容器提供完全基于 Java 的配置,但这种方法在试行一段时间之后,甚至能作为完整里程碑的时候,我们对这种方法进行了反思;这种方法并不能完全满足我们的设计目标。一次完整的设计迭代之后,我们把目前的方法做成了 @Enable* 注解。

我们很早就开始支持 Servlet 3.0 容器,也遇到了一些容器实现自身的问题。我们不得不和实现容器的团队一起做一些迭代,来确保实现是正确的。

不过真正的主要原因是我们有意地扩大了范围,好让 3.1 就包括对 Java 7 提供支持,而不是等到 3.2 再开始。这主要围绕对 fork/join 的支持和 JDBC 4.1。我们还决定,要尽可能早地支持 Hibernate 4,甚至在他们发布最终版本之前。目前我们用的是 Hibernate 4 的 RC 7 版本,实际上我们的发布版本也基于 RC 7,所以 Hibernate 4.0 的最终版本一旦可用,Spring 3.1.1 就会立即升级去支持 Hibernate 4.0 最终版。

另外值得一提的是,我们不想让时间追着跑,而是尽可能提供最好的版本。所以它是连续、完整的,也能保证对用户来说是真正有意义的。

InfoQ:Spring 对 Java 7 提供了支持,这是不是能直观反映出 Java 7 的运用会比 Java 5 和 Java 6 更为迅速?

我认为是有可能的。Open JDK 和 IBM 都已经发布了 JDK 7,这是个好迹象。我们可以预测,选择基于 OpenJDK 7 的 Tomcat 7 是自然而然的。

我们当然希望 Java 7 能被迅速采用,在一定程度上,我们也希望能助它的推广和提升一臂之力。如果 Spring 有一个版本能为人们打开一道门,或许 Java 7 的推广能变得更加容易一些。

InfoQ:Spring 3.1 还利用了 Java 7 的其他哪些功能?像 try-with-resources 或其他 Project Coin 功能使用了么?

我们一直记着这些功能,还有 Java 8 里的语言特性,但 Spring 3.1 并没有过多地利用它们。大部分新特性在针对特定 API 的时候都很方便,比如 multi-catch、try-with-resources 和 switch 语句支持 String,而不像泛型这种语言特性会直接影响 API 供应商。值得注意的是,Spring 3.2 将会关注 JMS 2,并有可能和 try-with-resources 保持一致。让我们拭目以待。

InfoQ:你刚刚提到你们引入了环境抽象的概念。能给我们一个在哪里会使用它的例子么?

环境支持实际上可以分为两类:一类是属性源抽象的概念,第二类是 Bean 定义 Profile。

就属性源来说,你要是琢磨过 Java 设计,就知道获取属性的方式有很多,比如系统环境变量、JVM 系统属性、真正的 Map 或 Property 对象,或从数据库或键值存储里获得。但从语义上来说,这些属性都有共同点。它们基本上都是改变环境的配置属性。那属性源抽象就是个简单的 SPI(服务提供者接口),其实现能为应用配置提供键值对形式的后端存储。把属性源抽象加到 Spring 环境里的具体做法是,由环境维护这些你能操作和查询的属性源的层次化结构。举例来说,Spring 的 StandardEnvironment 适用于独立应用,直接使用时可以带有表示环境变量和 JVM 系统属性的属性源。对 Web 应用来说,Spring 的 StandardWebEnvironment 会把 Servlet 的 init-params、context-params 和 JNDI 属性源混杂在一起。Environment 已经深度集成到了整个容器和 Spring 的 property-placeholder 机制里;这个概念能提供一致的抽象,这样你就可以说:“Spring,告诉我这个属性的值”,应用也不需要知道或关心这个值从哪里来。

第二部分是 Bean 定义 Profile,这通常能让你基于应用的部署环境(比如开发环境、测试环境、生产环境,或者相对于传统环境的云环境)有条件地注册 Bean 定义。所以举例来说,相对于生产环境,你可以在开发环境下使用 Spring 的 JDBC 命名空间和嵌入式数据库构建器等内容来预设一个嵌入式数据库,然后在生产环境里,应用可以从 JNDI 获取数据源。

过去一段时间里我们发现有很多这样的需求,目前这也能被很好地接受了。我们希望看到人们用各种方式把它利用起来。

InfoQ:本次发布的另一个重磅内容是 Spring Cache。Spring Cache 和 Spring Data 项目是怎么协调的?

Spring 3.1 的缓存抽象是个 SPI,主要包括需要由后端缓存提供者去实现的 Cache 和 CacheManager 接口。然后还有一些共同构成声明性编程模型的注解,比如 @Cacheable、@CachePut、@CacheEvict 等。

Spring Data 实际上是个大型项目,是一组项目的集合,旨在利用模板类等大家熟悉的 Spring 机制来访问个人数据存储。这些数据存储本来有很多就适合做缓存,借助我们已经完成的集成工作,它们都可以直接使用了,比如说,GemFire 或 Redis 都是缓存提供者,因为针对 Cache 和 CacheManager 这两个 SPI,他们都提供了现成的实现。不论后端实现是什么,开发人员只需要关注 @Cacheable、@CachePut 等注解就可以了。

InfoQ:Spring Cache 和 JCache( JSR 107 )有多少重叠内容?

我觉得它们是互补的,规范已经完成了,那我们肯定会为自己的缓存管理器 SPI 提供有一个基于 JCache 的实现。你可以预想到,如果接口是 CacheManager,我们就会提供一个 JCacheCacheManager,就和我们用 Spring 内核发布一个 Ehcache 管理器一样。真正漂亮的是,目前的 SPI 和 Spring Data 是我们自己实现的。有了 JCache 之后,所有供应商都会尽可能采用它,他们差不多都会去实现 JCache 的 SPI,这会进一步提升 JCache 的嵌入能力,不论后端的提供者是什么。

在编程模型方面,注解有比较多的重叠,这在一定程度上是可预见的。因为两个东西在语义上就有很多重叠,在某些情况下也会使用同一个注解。所以 JCache 一旦完成之后,我们极有可能要对自己的注解和 JCache 的注解同时提供支持。Spring 2.5 里我们引入了自己的 @Autowired 注解,这个注解同时还要支持后来被 JSR-330 标准化的 @Inject 注解,现在的情况就跟这个非常类似。

InfoQ:你们跟踪 JSR 347 么?你认为它对 Spring Cache 有影响么?

我不是那个规范和领域的专家,但根据它自身的优点来看,它肯定是有意义的。现在已经有很多不同的数据网格和分布式缓存提供者了;他们往往采用不同的方式去完成相似的事情。我们需要一个所有人都认可的规范来统一语义,这个规范姗姗来迟,JSR 347 就是个很不错的选择。

鉴于 JCache JSR 还没全部完成,而 JSR-347 又是以它为基础的,所以进一步推测可能有点儿为时尚早。从 Spring 的角度看,JSR-347 可能不需要为我们提供的内容做太多事情。我们主要是为后端存储提供一致的编程模型和简单的 SPI。从 JCache 的角度来看,后端存储只不过是数据存储罢了。JCache 和 JSR-347 碰巧都是分布式的,这实际上有点儿重叠。这个情况可能和 Spring 对事务管理的支持差不多。我们已经有了注解的方式和 SPI,然后可能会出现数量不定的实现,其中之一就是 JTA,但从 Spring 用户的角度来看,这确实没什么影响;JSR-347 对 Spring Cache 是有影响,但从编程模型的角度来说并没有什么关系。

InfoQ:你提到 Spring 3.2 相关的几部分内容,比如 JMS 2.0 和 JCache。能和我们再多分享一些计划里的内容么?

好的。在规范方面,我们正在研究 JPA 2.1、Bean Validation 1.1。我们也会确保 Spring 和 JSF 2.2 能很好地协作。除此之外,还有好几个我们尚未完全确认的研究领域,但我们会继续深入研究,比如并发编程方法。对于 Spring 3.1 要集成一个 fork/join 池,我们已经提供了一些非常基本的支持,但随着 fork/join 等内容的引入,应用开发模型会发生什么样的变化呢?我觉得不仅仅是 Spring,更大范围的社区对这个问题也都还没有答案。所以最高目标是,不光要搞明白这个问题,还要提供一些指导、给出一些示例应用等。

异步编程模型也是一样。对 Java 开发人员来说,Servlet 3.0 里现在就有异步工具,它们本身运行得很好,但怎么从 Spring 等 Web 框架里集成它们还悬而未决。如果你有一个启用了异步功能的 Servlet,请求管道里的其他 Servlet 组件就需要知道异步情况,所有的过滤器等也都是一样。那些 Servlet 组件要不要达到这个目标,并重构所有内容呢?对最终开发人员来说这意味着什么?对框架来说又如何呢?其他框架和我们所作的有哪些不同呢?

我们也想继续关注应用开发在云里会有怎样的变化。目前我们所了解的是一些 PaaS 提供者,它们都能正确处理那些并发访问他们平台的基于 Java 的负载;所以应用开发主要是基于 war 的部署模式和基于 Servlet 的应用。但有一个问题确实值得我们思考一下,就是“用云的特性来处理这些内容是否就是最好的方式呢?”

Chris 也谈到,他们正在重新考虑 Spring 的错误报告机制,以便配置错误相关的堆栈跟踪信息能少一些,让它能和 javac 的输出更相似;还要找一个更为现代和易于使用的工具来替换掉 CGLib 代理。Spring 框架的版本控制工具也会把 Subversion 换成 Git(Hub),从 3.2 开始,构建系统也会从 Ant/Ivy 换成 Gradle。

Spring 3.2 的时间表相当乐观,计划会在 2012 年的第四季度发布,大体上会遵循上面提到的那些规范。

查看英文原文 Spring 3.1 is GA Today - Adds Java 7 Support, Environment Abstraction and Cache Abstraction

2012 年 1 月 15 日 10:183819
用户头像

发布了 151 篇内容, 共 52.2 次阅读, 收获喜欢 9 次。

关注

评论

发布
暂无评论
发现更多内容

MyBatis 3 解析Mapper映射配置

杨家昌

mybatis 配置 Mapper XMLMapperBuilder

算法篇之数组右移

月夜

算法 数组右移

关于架构的几件小事:架构是什么

北风

架构 企业架构

jenkins集成maven获取远程项目

kcnf

牛排等级之美国篇

地藏@易果18916037281

为什么很多技术都觉得前端很简单?

极客时间

前端 前端开发 前端工程

没有业务规则的技术实现

wd

吐槽

最好的汇报是不需要汇报

伯薇

团队管理 领导力 沟通 汇报 可视化

测试驱动开发英制单位转换

escray

学习 CSD 认证实战营

深入理解Java中的Lambda表达式和函数式编程的关系

jerry

Lambda java8 函数编程

Redis学习笔记(散列类型)

编程随想曲

redis

Ubuntu 20.04 装机手册

小柒

Linux #Ubuntu #geek

关于 DeepL 机器翻译能力

梁帅

产品 互联网 机器翻译 谷歌Google DeepL

iTerm2使用小技巧-密码管理器

小菜与老鸟

iTerm

回"疫"录(9):守住我们自己的净土

小天同学

疫情 回忆录 现实纪录 纪实

地址收录

gogogo

性能优化第一课:性能指标

kimmking

性能优化

Java并发编程基础--Synchronized

Java收录阁

线程

在 TypeScript 处理空值异常

寇云

typescript 前端开发

开源一个自研的基于Netty的高性能网络通信框架

Geek_373e87

TCP dubbo Netty

一种消息消费失败的处理方案

redis kafka

小米手机广告在日本「炸」了,背后的教训是什么?

葛仲君

产品 本地化 小米 日本 文化

央行:取消境外机构投资者额度限制,推动金融市场进一步开放

kimmking

自助设备系列——自助设备的春天

孙苏勇

产品

讨论:应不应该用存储过程?

kimmking

第一篇InfoQ的博客

程序员小岑

写作 体验

我为什么不买Mac

Winann

效率 效率工具 Mac apple

专题:快速开发那点事儿 | 轮子怎么选

HPioneer

Java 敏捷开发 Ruoyi 快速开发

hive 建表语句迁移

杨飞

spring boot 集成 elasticsearch 7.x (一)

wd

elasticsearch high level client

这样理解Java中的函数式编程就对了

jerry

java8 函数编程

Spring 3.1发布GA版本了-InfoQ