To be fair, the Java EE community is still simplifying the Java EE APIs and making them more feature rich. In Java 7, a new form of the try/catch block was introduced to the JDBC API, namely Try-with-Resources. Objects can register themselves as resources to the Java VM by implementing the Closeable or AutoCloseable interfaces.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I'm sure we'll see simplifications to the Spring JdbcTemplate API to support Try-with-Resources in the future, but since resource leaks are not a problem with this API, it probably won't be a core feature of the Spring platform until Spring requires Java 7.
Another Jdbc Answer: RowSet improvements
JDBC is also moving forward with the new implementations of the RowSet API. This API will allow for disconnected sets of records to be modified at the client tier or the Web tier and will allow for changes to be sent back to a server. No doubt the Spring development team will examine this API and find a way to adopt it or support it. Development teams that really need that functionality now can simply run their Spring application on Java 7 and use the JDBC 4.1 API directly.
Review: APIs versus language features
The reason the JdbcTemplate API works so well is its simplicity. Allow the called method to set up the process, call the new lines of code and tear down the structures where needed. None of the innovations in the JdbcTemplate needed changes to the Java virtual machine. The last time it went through major revisions was when the Java world moved to Java 5 and generics, which it has supported since Spring 2.5.
For many cases, a simple API will cover a requirement just as well as a change to the language, and it can do so without forcing people to upgrade their low-level infrastructure. I am glad to see the Java development kit adopt a better stance on cleanup processing, but I still find the JdbcTemplate API superior for many types of processing, right out of the box.
Transaction management in JDBC and Java EE
The Spring development team knew, back in the mid-2000s, that there were several things keeping developers from writing portable code, i.e., code that could move from one application server to another. One of those things was transaction management.
JDBC itself has support for transaction management in the form of the connection's commit method and the setAutoCommit(false) call on the connection. This transaction management is 100% manual, and is not tied to any application server or container.
Java EE supports its own transaction models, which run in two ways. One: The Java EE container (application server) that runs the Enterprise Java Beans (EJBs) can provide container-managed transactions that are automatically applied based on a set of rules added to the EJB definitions. Or, two: Users can look up the JNDI UserTransaction Bean, and call the appropriate commit, rollback or other methods manually.
Spring doesn't care what you use
Following the basic tenet that a change to configuration shouldn't mean a change to business code, Spring provides a standard transaction model that is coded the same way whether an application runs in a Java EE Web application server, a simple Tomcat or Jetty servlet container, or even on the command line from a Java main() method.
Spring has a simple transaction API that can be invoked via annotations such as @Transactional, an aspect-oriented pointcut (for mapping methods to transactions by convention) or via a TransactionTemplate API. Regardless of which transaction platform a development team uses, the code their beans use does not change.
Abstractions are the key to tolerating platform changes
All enterprise abstraction APIs in Spring are interface driven. In cases where the API wraps several choices, such as with transactions or the Object to XML Mapping (OXM) API, those mappings can be set up in the application configuration code, and business code does not have to change. For example, transactional code does not change if it's moved from a simple command-line program to one deployed as a WAR on Tomcat or an EAR on IBM WebSphere on a Z-OS mainframe Linux installation.
The only changes that need to be made are to the configuration. These can take the form of XML bean configuration files, annotations in the source code or instructions in the form of Java code that uses Spring's JavaConfig syntax.