JDBC 4.0 Enhancements in Java SE 6by Srini Penchikala
Java Platform, Standard Edition (Java SE) version 6 (code name Mustang), is currently in its second beta release and is scheduled to be delivered in October of this year. Java SE 6 includes several enhancements to the Java Database Connectivity (JDBC) API. These enhancements will be released as JDBC version 4.0. The main objectives of the new JDBC features are to provide a simpler design and better developer experience. This article provides an overview of the JDBC 4.0 enhancements and what benefits they offer to enterprise Java developers. We will explore the new JDBC features with the help of a sample loan processing application using Apache Derby as the back-end database.
Java SE 6.0
RowId support to the additional
JDBC 4.0 Features
Thanks to the Java SE Service Provider mechanism included in Mustang, Java developers no longer need to explicitly load JDBC drivers using code like
Class.forName() to register a JDBC driver. The
DriverManager class takes care of this by automatically locating a suitable driver when the
DriverManager.getConnection() method is called. This feature is backward-compatible, so no changes are needed to the existing JDBC code.
JDBC 4.0 also provides an improved developer experience by minimizing the boiler-plate code we need to write in Java applications that access relational databases. It also provides utility classes to improve the JDBC driver registration and unload mechanisms as well as managing data sources and connection objects.
With JDBC 4.0, Java developers can now specify SQL queries using
Annotations, taking the advantage of metadata support available with the release of Java SE 5.0 (Tiger). Annotation-based SQL queries allow us to specify the SQL query string right within the Java code using an
Annotation keyword. This way we don't have to look in two different files for JDBC code and the database query it's calling. For example, if you have a method called
getActiveLoans() to get a list of the active loans in a loan processing database, you can decorate it with a
@Query(sql="SELECT * FROM LoanApplicationDetails WHERE LoanStatus = 'A'") annotation.
Also, the final version of the Java SE 6 development kit (JDK 6)--as opposed to the runtime environment (JRE 6)--will have a database based on Apache Derby bundled with it. This will help developers explore the new JDBC features without having to download, install, and configure a database product separately.
The major features added in JDBC 4.0 include:
- Auto-loading of JDBC driver class
- Connection management enhancements
- Support for
DataSetimplementation of SQL using
- SQL exception handling enhancements
- SQL XML support
There are also other features such as improved support for large objects (BLOB/CLOB) and National Character Set Support. These features are examined in detail in the following section.
Auto-Loading of JDBC Driver
In JDBC 4.0, we no longer need to explicitly load JDBC drivers using
Class.forName(). When the method
getConnection is called, the
DriverManager will attempt to locate a suitable driver from among the JDBC drivers that were loaded at initialization and those loaded explicitly using the same class loader as the current application.
getDrivers have been enhanced to support the Java SE Service Provider mechanism (SPM). According to SPM, a service is defined as a well-known set of interfaces and abstract classes, and a service provider is a specific implementation of a service. It also specifies that the service provider configuration files are stored in the
META-INF/services directory. JDBC 4.0 drivers must include the file
META-INF/services/java.sql.Driver. This file contains the name of the JDBC driver's implementation of
java.sql.Driver. For example, to load the JDBC driver to connect to a Apache Derby database, the
META-INF/services/java.sql.Driver file would contain the following entry:
Let's take a quick look at how we can use this new feature to load a JDBC driver manager. The following listing shows the sample code that we typically use to load the JDBC driver. Let's assume that we need to connect to an Apache Derby database, since we will be using this in the sample application explained later in the article:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver"); Connection conn = DriverManager.getConnection(jdbcUrl, jdbcUser, jdbcPassword);
But in JDBC 4.0, we don't need the
Class.forName() line. We can simply call
getConnection() to get the database connection.
Note that this is for getting a database connection in stand-alone mode. If you are using some type of database connection pool to manage connections, then the code would be different.
Prior to JDBC 4.0, we relied on the JDBC URL to define a data source connection. Now with JDBC 4.0, we can get a connection to any data source by simply supplying a set of parameters (such as host name and port number) to a standard connection factory mechanism. New methods were added to
Statement interfaces to permit improved connection state tracking and greater flexibility when managing
Statement objects in pool environments. The metadata facility (JSR-175) is used to manage the active connections. We can also get metadata information, such as the state of active connections, and can specify a connection as standard (
Connection, in the case of stand-alone applications), pooled (
PooledConnection), or even as a distributed connection (
XAConnection) for XA transactions. Note that we don't use the
XAConnection interface directly. It's used by the transaction manager inside a Java EE application server such as WebLogic, WebSphere, or JBoss.
RowID interface was added to JDBC 4.0 to support the
ROWID data type which is supported by databases such as Oracle and DB2.
RowId is useful in cases where there are multiple records that don't have a unique identifier column and you need to store the query output in a
Hashtable) that doesn't allow duplicates. We can use
getRowId() method to get a
setRowId() method to use the
RowId in a query.
An important thing to remember about the
RowId object is that its value is not portable between data sources and should be considered as specific to the data source when using the
update methods in
ResultSet respectively. So, it shouldn't be shared between different
DatabaseMetaData can be used to determine the lifetime validity of the
RowId object. The return value or row id can have one of the values listed in Table 1.
|ROWID_VALID_OTHER||Lifetime of the
|ROWID_VALID_TRANSACTION||Lifetime of the
|ROWID_VALID_SESSION||Lifetime of the
|ROWID_VALID_FOREVER||Lifetime of the