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:
- Inversion of control explained fast with a Spring IoC example
- Spring MVC Java web development with Spring Boot
- Drawbacks to IoC and how to solve inversion of control problems
- Spring IoC vs. Google Guice's inversion of control approach
- Getting started with Google Guice
- Getting started with the Spring IoC container
- The beauty of Spring without XML: Annotation based IoC
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.
Here are some other helpful tips, tricks, tutorials and examples by Cameron McKenzie (@cameronmcnz):