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.

Updated inversion of control (IoC) tutorials and dependency injection examples

TheServerSide has been updating its resources in terms of the Spring framework, Java EE contexts and various different approaches to inversion of control (IoC) and dependency injection (DI). Check out these newer resources on the topic:

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 vs Hibernate and simple JDBC 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, regardless whether the underlying database driver is JDBC or ODBC based.

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 JDBC 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, JDBC transactional code does not change if it's moved from a simple command-line program to one deployed as a WAR EAR or JAR.

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

Next Steps

Here are some other helpful tips, tricks, tutorials and examples by Cameron McKenzie (@cameronmcnz):

Getting started with Git: The 5 basic Git commands everyone needs to know

A RESTful APIs tutorial: The principles of effective web service design

Microservices deployment? How to embed Tomcat in an executable JAR

Continuous integration quickstart: A step-by-step Jenkins tutorial for beginners

Undo bad commits with this git reset hard example tutorial

Dig Deeper on Spring framework

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.