Jdbc4Transition

From Eigenpedia

Jump to: navigation, search

Contents

Background

Breaking changes from JDBC 3 to JDBC 4 are hindering Farrago's transition from JDK 1.5 to JDK 1.6. We would like to have a transition period during which both JDK's are supported.

The challenge is that in JDBC 4, some existing java.sql interfaces have new methods added, and those new methods reference new java.sql interfaces. When we add references to those new interfaces in our JDBC classes, then our code becomes incompatible with JDK 1.5. If we omit the new methods, then our code remains incompatible with JDK 1.6. See http://blog.punchbarrel.com/2008/09/23/java-6-breaks-jdbc for more.

There have been various attacks on this (see #Mailing List Discussions). The next section documents the approach we are actually planning to take.

Proposed Approach

To solve the problem above, we are going to use a slightly shady build hack.

Let's consider one of the affected Farrago classes: 

import java.sql.*;
...
public class FarragoJdbcEnginePreparedStatement implements PreparedStatement
{
...
    public void setRowId(int i, RowId rowid)
        throws SQLException
    {
        throw new UnsupportedOperationException("setRowId");
    }
}

java.sql.RowId is one of the new interfaces introduced in JDBC 4.

First, add another entry to the import list above: 

import java.sql.*;
import org.eigenbase.jdbc4.*;
...

(Note that it's necessary to import by .* here, for reasons which should become clear soon.)

Now, change the Farrago build so that for JDK 1.5, we create a source file as follows: 

package org.eigenbase.jdbc4.RowId;

public interface RowId
{
}

But for JDK 1.6, do not create any such source file. (Otherwise, attempting to compile FarragoJdbcEnginePreparedStatement will result in an import ambiguity error.)

Now, when we compile under 1.5, we'll pick up the org.eigenbase.jdbc4 dummy. When we compile under 1.6, we'll pick up the real java.sql.RowId.

Build Details

To implement the above approach, I'm creating a new farrago/jdbc4 directory containing the dummy source files. Farrago's build.xml checks property ant.java.version, and copies the source files to farrago/src/org/eigenbase/jdbc4 only if the version is JDK 1.5.

For now, the dummies are just empty interfaces; if we actually want to start implementing some of JDBC 4, we can copy the necessary declarations from java.sql on demand.

Once we drop support for JDK 1.5, we can eliminate package org.eigenbase.jdbc4 altogether.

eigenjira:FRG-372 describes a known issue running on 1.6; this needs to be investigated and fixed.

Client Compatibility

The general policy for Farrago is to segregate client driver dependencies (enforced via macker) so that these can be compiled to target older JVM's. The rationale is that we would like to be able to support connectivity from as many applications as possible, even older ones stuck on legacy JVM's.

For Farrago builds on JDK 1.5, we'll continue to support JVM 1.4 client compatibility.

For Farrago builds on JDK 1.6, we'll support JVM 1.5 client compatibility.

This means that if we start implementing any of the new JDBC 4 functionality, we'll need to either compile multiple client driver versions, or figure out how to make a one-size-fits-all client, maybe using the olap4j factory technique described by Julian.

Mailing List Discussions

Other Approaches

hersker did some quick research on approaches to the transition from JDBC3 to JDBC4. This is by no means exhaustive or ironclad:

Derby 10.2 seems to expect developers to build the JDBC 4.0 drivers themselves. http://wiki.apache.org/db-derby/TenTwoRelease#head-780ae0f319ba5551646bfad39c8cdb6cb1e019f2

Postgres 8.2 and 8.3 offer distinct JDBC 3- and 4-compatible driver JARs for download. http://jdbc.postgresql.org/download.html According the download page, " JDK 1.6 - JDBC4. Support for JDBC4 methods is limited. The driver builds, but the majority of new methods are stubbed out."

Older versions of postgres appear to use the dynamic proxy approach. However, bugs like this http://archives.postgresql.org/pgsql-jdbc/2007-04/msg00007.php indicate that the JDBC 4.0 methods were not implemented, causing runtime errors.

HSQLDB website does not mention anything beyond JDBC 2 support. I grepped around in the 1.8.0 source we are currently using for Farrago and found no advanced JDBC methods.

Oracle's 10.2g driver download page references JDK compatibility up to 1.5. No mention of 1.6. http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc_10201.html

The SQLServer download page http://www.microsoft.com/downloads/details.aspx?familyid=f914793a-6fb4-475f-9537-b8fcb776befd&displaylang=en says "JDK 1.4 or later" but I suspect this is stale. I used javap to look at some of the classes in open/thirdparty/sqlserverjdbc/enu/sqljdbc.jar and I don't see any JDBC 4 extensions methods.

The jTDS driver http://sourceforge.net/project/showfiles.php?group_id=33291 seems to only offer JDBC 3-compatible version. I could not find mention of JDBC 4.0 on their site.

MySQL's Connector/J download page http://www.mysql.com/products/connector/j/ refers to JDBC 3.0 but nothing newer.

Retrieved from "http://pub.eigenbase.org/wiki/Jdbc4Transition"
Personal tools