公平地说，Java EE社区仍然在简化Java EE API，并让它们的功能更丰富。在Java 7中，一种新形式的try/catch块介绍给了JDBC API，命名为Try-with-Resources。对象可以通过实现Closeable或者AutoCloseable接口，把自己作为资源注册到Java VM中。

　　我相信我们将会看到简化的Spring JdbcTemplate API来支持Try-with-Resources，但自从使用此API之后，资源泄漏已经不是问题，那么直到Spring需要Java 7之前，它可能不会成为一个核心功能。

　　另一个Jdbc答案：RowSet的改进

　　JDBC也随着新的RowSet API的实现而向前发展。这个API将允许在客户端层或者Web层断开要修改的记录集合，并且允许将更改发送回服务器。毫无疑问Spring开发团队将检查这个API并找到一种方法来接受或支持它。开发团队现在真的需要这个功能，因为它可以简单地在Java 7上运行他们的Spring应用程序和直接使用JDBC 4.1 API。

　　点评：API与语言特性

　　JdbcTemplate API能很好工作的原因在于其简单有效。允许被调用的方法来设置过程，调用新的代码行和在需要的地方拆除结构。没有一个JdbcTemplate 里的创新需要更改为Java虚拟机。它经历的最后一次重大修改是当Java升级到Java 5和泛型时，这是从Spring 2.5开始以来已经支持的。

　　许多情况下，一个简单的API将覆盖一个需求，比如改变了语言，也不会迫使人们升级他们的底层基础设施。我很高兴看到Java开发工具包在清理处理上，采用更好的立场，但我还是觉得JdbcTemplate API对于许多类型的处理更优越、开箱即用。

　　JDBC和Java EE中的事务管理Spring开发团队知道，早在2000年，就有几件事情让开发人员编写可移植代码，例如，

　　代码可以从一个应用程序服务器移动到另一个服务器。这些事情其中之一是事务管理。

　　JDBC本身是以连接的提交方法的形式支持事务管理的，setAutoCommit(false)调用连接。这个事务管理是100%手工的,并不依赖于任何应用程序服务器或容器。

　　Java EE支持它自己的事务模型,它以两种方式运行。一是：运行企业Java bean(EJB)的Java EE容器(应用程序服务器)，可以提供容器管理的事务，将基于添加到EJB定义的一组规则自动应用。或者是：用户可以查找JNDI UserTransaction Bean，并手动调用适当的提交、回滚或其他方法。

　　Spring不会在意你用什么

　　遵循改变配置不应该意味着改变业务代码，Spring提供了一个标准的事务模型，相同的编码方式是运行在Java EE Web应用程序服务器,还是简单的Tomcat或Jetty servlet容器，或甚至是在从Java 主方法的命令行中。

　　Spring有一个简单的事务API，可以通过注释调用，比如@transactional等，一个面向方向的切入点(按照惯例把方法映入到事务上)或通过一个TransactionTemplate API。无论开发团队使用哪个交易平台，他们的bean使用的代码不会改变。

　　抽象是容忍平台变化的关键

　　所有企业在Spring中的抽象API都是接口驱动。在某些情况下API覆盖几个选择，例如事务或对象到XML的映射(OXM)API，这些映射可以在应用程序配置代码中设置，并且不需要更改业务代码。例如，事务代码不用改变，如果它已经从一个简单的命令行程序迁移到作为一个WAR部署在Tomcat上，或者一个EAR部署在一个安装Linux的Z-OS主机的IBM WebSphere上。

　　需要做的唯一改变就是配置。这些可以是用XML bean形式的配置文件，源代码中进行注释或Java代码形式的说明，这些都使用Spring JavaConfig语法。

　　相关文章：
　　Spring摘要：Spring框架仍然有重大作用
　　Java EE对比Spring：两者并非完全等效