Spring 3.1发布GA版本了

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