Skip site navigation (1) Skip section navigation (2)

JDK 1.4 challenge, opinions please

From: Rene Pijlman <rene(at)lab(dot)applinet(dot)nl>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: JDK 1.4 challenge, opinions please
Date: 2001-12-16 21:43:37
Message-ID: (view raw or flat)
Lists: pgsql-jdbc
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,

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
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

A simple solution would be to move such methods from jdbcge2 to
jdbc2 and jdbc3, but this would create an awfull lot of code

So I'm inclined to refactor the code and create wrapper methods
in jdbc2 and jdbc3 that call common code in helper methods in

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

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.

René Pijlman <rene(at)lab(dot)applinet(dot)nl>


pgsql-jdbc by date

Next:From: Serge DubakovDate: 2001-12-17 07:53:05
Subject: PostgreSQL JDBC - trouble with catching exceptions
Previous:From: Barry LindDate: 2001-12-16 04:31:59
Subject: Re: JDBC 3.0 / JDK 1.4 build issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group