New Java features bring the JDBC API closer to Spring

Innovations from the Spring framework have spurred advances in the JDBC API which are now helping the Spring framework evolve.

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.

Part one: Why Spring is still relevant

Part two: Compare and contrast Java EE and Spring

Part three: JDBC chases Spring

Part four: The case for Spring

Part five: Refuting the case against Spring

This was last published in January 2013

Dig Deeper on Spring framework

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.