Re: JDBC 3.0 / JDK 1.4 build issues

On Sun, 9 Dec 2001 07:14:01 -0800 (PST), you wrote:
>Oh yeah. That's right.  Since org.postgresql.jdbc2.Connection is a
>'complete' implementation of java.sql.Conenction, it cannot compile
>cleanly with jdk1.4.  So, one cannot inherit from the jdbc2.Connection
>object.  It has to be a clean jdbc3 Connection.  Ugh.

And how about this code reorganization scheme?

org/postgresql/Connection.java
package org.postgresql;
public abstract class Connection
// Contains code that is common to jdbc1, jdbc2 and jdbc3

org/postgresql/Connection2.java
package org.postgresql;
public abstract class Connection2
extends org.postgresql.Connection
// Contains code that is common to jdbc2 and jdbc3,
// but cannot compile with jdbc1

    org/postgresql/jdbc1/Connection.java
    package org.postgresql.jdbc1;
    public class Connection
    extends org.postgresql.Connection
    implements java.sql.Connection
    // ant: only compiled when JDBC1
    // Contains code that is valid only for jdbc1

    org/postgresql/jdbc2/Connection.java
    package org.postgresql.jdbc2;
    public class Connection
    extends org.postgresql.Connection2
    implements java.sql.Connection
    // ant: only compiled when JDBC2
    // Contains code that is valid only for jdbc2

    org/postgresql/jdbc3/Connection.java
    package org.postgresql.jdbc3;
    public class Connection
    extends org.postgresql.Connection2
    implements java.sql.Connection
    // ant: only compiled when JDBC3
    // Contains code that is valid only for jdbc3

Perhaps Connection2.java should go in the jdbc2 package.

I'll see if I can get this to work with 1.3/1.4.

>(And in both cases, we still have the ant vs. make discussion
>to solve) thoughts? Ideas on how can simplify this so jdbc4 doesn't
>do this to us again? (Or is this accecptable/normal situation?)

Another interesting idea is to build all versions of the driver
into one .jar file and choose the right classes at runtime
(using reflection in JDK >= 1.1). This would reduce the number
of driver versions we have to distribute and would make
deployment easier. Building the driver this way would be more
complicated though, since it requires all JDK versions to be
available on the build platform. Just a thought :-)

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