Tutorial:

New Java features bring the JDBC API closer to Spring

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.

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.

Ken Rimple's Spring summary

This is part three of a five-part series. Check out the other parts below.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.