Although every enterprise application must access a database for persistent storage, there is no single best way or best practice for Java data access. The only common feature among the various solutions is that at some point JDBC is used to interact with the database server.

Although JDBC 4 has made great strides toward an easier-to-use API, writing pure JDBC code is still a rather tedious task. This is brought home in Vikram Veeravelu recent java.net article that compares coding with plain JDBC to using the Spring framework to reduce database code complexity:

Spring JDBC implements the Template design pattern, meaning the repetitive plumbing parts of the code are implemented in template classes. This approach simplifies the use of JDBC, since it handles the creation and release of resources. This helps to avoid common errors like forgetting to close the connection. It executes the core JDBC workflow tasks like statement creation and execution, leaving application code to provide SQL and extract results.

In Veeravelu's article, the use of Spring's JDBC framework reduces the code required for the simple DAO example by about fifty percent.

In addition to code reduction, Spring's JDBC has a more developer-friendly exception hierarchy than what JDBC alone provides:

When dealing with exceptions, Spring examines the metadata available from a database connection to determine the database product. It uses this knowledge to map SQLException to the correct exception in its own hierarchy. So, we need not worry about proprietary SQL state or error codes; Spring's data access exceptions are not JDBC-specific, so your DAOs are not necessarily tied to JDBC because of the exceptions they may throw.

Unfortunately, the article fails to mention how Spring's exception hierarchy will work in the context of JDBC 4. As we noted in an earlier Artima article on JDBC 4, the latest JDBC spec provides a much more refined exception hierarchy than its predecessors did. Notable are the divisions of JDBC 4 exceptions into transient and non-transient exceptions. An SQLTransientException indicates failure of an operation that might succeed if retried. For instance, attempting to connect to a database server may result in a transient JDBC exception, indicating to the caller that the connection attempt should be retried.

Reading Veeravelu article raises the question of why anyone would write high-level application code directly to JDBC when frameworks such as Spring, or even O/R mapping frameworks, so vastly simplify database access.

One reason I can think of is the desire to avoid tying code to any specific framework apart from the "pure" Java stack. But is that a valid reason for incurring almost twice as much code as would be possible with, say, Spring's JDBC support? Are there other reasons for writing application code directly to JDBC?