I'm working on JDK 1.4 / JDBC 3.0 compatibility and I've
encountered a challenge. I'd appreciate your opinions on the
proposed solution.
A quick recap: in order to support JDK1.4 / JDBC 3.0 we must add
some new methods to a couple of classes. Unfortunately, this is
not trivial, since some of these methods use new types. The
modified classes don't compile with JDK 1.2/1.3 / JDBC 2.0,
therefore.
The solution I'm working on is to introduce a new directory
(jdbcge2, meaning "greater than or equal to 2"), which contains
all code that is common to JDBC 2.0 and 3.0. The directory jdbc2
will contain only code that is specific to 2.0 and the new
directory jdbc3 will contain only code that is specific to 3.0.
Concrete classes in jdbc2 and jdbc3 extend abstract classes in
jdbcge2. Methods in jdbc2 and jdbc3 implement the appropriate
java.sql.* interfaces, methods in jdbcge2 do not.
Now the problem: there are many methods in DatabaseMetaData.java
that create a ResultSet. However, the common implementation in
jdbcge2/DatabaseMetaData cannot create a ResultSet, since the
type of the ResultSet is unknown (it's an
org.postgresql.jdbc2.ResultSet or an
org.postgresql.jdbc3.ResultSet, depending on the compilation
environment).
A simple solution would be to move such methods from jdbcge2 to
jdbc2 and jdbc3, but this would create an awfull lot of code
duplication.
So I'm inclined to refactor the code and create wrapper methods
in jdbc2 and jdbc3 that call common code in helper methods in
jdbcge2.
This applies to the following methods in DatabaseMetaData:
- getProcedures
- getProcedureColumns
- getTables
- getSchemas
- getTableTypes
- getColumns
- getColumnPrivileges
- getTablePrivileges
- getBestRowIdentifier
- getImportedExportedKeys
- getTypeInfo
- getIndexInfo
Do we agree that this refactoring - touching lots of code - is
desirable?
This idea may apply to jdbc1 as well, which would allow us to
reduce the amount of code duplication that currently exists
between jdbc1 and jdbc2.
There are other problems up ahead though, such as common code in
jdbcge2 that references constants from java.sql (e.g.
FETCH_FORWARD). I'm not sure yet if we can resolve that easily
without code duplication.
An alternative approach we should consider is some sort of
preprocessing in the build process (#ifdef JDBC3). But that's
generally considered un-javaish and it would inconvenience
building and debugging the driver with standard IDE's.
Regards,
René Pijlman <rene@lab.applinet.nl>