Обсуждение: JDK 1.4 challenge, opinions please

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>

On Sun, 2001-12-16 at 14:43, Rene Pijlman wrote:
> 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).

Couldn't the method that creates the resultSet to be used/abused be an
abstract method that the jdbcge2/DatabaseMetaData calls?  For instance,
jdbcge2/DatabaseMetaData has a protected method
   protected  ResultSet getResultSet();
and then the jdbc2/DatabaseMetaData and jdbc3/DatabaseMetaData classes
that inherit from jdbcge2/DatabaseMetaData implement it to return the
proper one?  Then jdbcge2/DatabaseMetaData can set the needed data in
the ResultSet.  You could also then have an empty method in
jdbcge2/DatabaseMetaData that can be overriden so the subclasses can
make more changes when the initial jdbcge2 stuff is done. (Kinda like
adding in a hook)

Did that make sense? ;-)



> 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>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--

Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>

D08C2F45:  28E7 56CB 58AC C622 5A51  3C42 8B2B 2739 D08C 2F45

On 17 Dec 2001 09:46:41 -0700, you wrote:
>Couldn't the method that creates the resultSet to be used/abused be an
>abstract method that the jdbcge2/DatabaseMetaData calls?  For instance,
>jdbcge2/DatabaseMetaData has a protected method
>   protected  ResultSet getResultSet();
>and then the jdbc2/DatabaseMetaData and jdbc3/DatabaseMetaData classes
>that inherit from jdbcge2/DatabaseMetaData implement it to return the
>proper one?  Then jdbcge2/DatabaseMetaData can set the needed data in
>the ResultSet.

Yes, this looks like a better idea. Its amazing how
non-intuitive Object Orientation can be :-) I'll continue on
this path.

>Did that make sense? ;-)

Very much so! Thanks for pointing me in the right direction.

And I wrote:
>> There are other problems up ahead though, such as common code in
>> jdbcge2 that references constants from java.sql (e.g.
>> FETCH_FORWARD).

This turns out to be a non-problem. I just needed to qualify the
constants with the java.sql.Interface prefix, since the class
containing this code no longer implements the interface.

There may be some cases of constants that exist only in some
versions of the JDBC API, but this can be handled with a similar
inheritance workaround as you described for creating
ResultSet's.

Regards,
René Pijlman <rene@lab.applinet.nl>