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

Re: JDBC 3.0 / JDK 1.4 build issues

From: Ned Wolpert <wolpert(at)yahoo(dot)com>
To: Rene Pijlman <rene(at)lab(dot)applinet(dot)nl>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC 3.0 / JDK 1.4 build issues
Date: 2001-12-09 15:14:01
Message-ID: 20011209151401.23349.qmail@web13409.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
--- Rene Pijlman <rene(at)lab(dot)applinet(dot)nl> wrote:
> On Sat, 8 Dec 2001 18:31:51 -0800 (PST), you wrote:
> >Hm.... if we cannot reuse the org.postgresql.Connection abstract class,
> >then won't we need to have a org.postgresql.jdbc3.Connection class that
> >extends org.postgresql.jdbc2.Connection?  Then will have to have the
> >Driver return the jdbc3 Connection when its called.  Won't that work?
> 
> Hangon, what would the definition of
> org.postgresql.jdbc2.Connection be in the new situation with
> jdbc3 classes inheriting from jdbc2 classes? 


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.

> I think there's a conceptual flaw in this scheme. Version 3 of
> the JDBC interfaces don't extend the version 2 interfaces, so I
> don't think we can solve it by letting jdbc3 classes extend
> jdbc2 classes.

True.  But I think its only affects Connection, PrepareredStatement
and CallableStatement.  (Which still sucks)  It means if that the ant
build script detected jdk1.4, it  must not attempt to build and jdbc1 
classes, and only classes outside of those three in the jdbc2 directory.
Either that or the classes in jdbc3 dir is a true 'fork' of the existing
classes.  Personally, I would like to see the jdbc3 dir, and the classes
would extend jdbc2 classes _when_ possible.  The three mentioned would 
have to be forked, but the others are saved.

So, we're left with two options.  The build process is about to get 
'more' ugly as we go into the jdbc3 process.  If we fork, the build
process is 'as ugly' as it currently is, but we will then have a forked 
code set.  (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?)  

=====
Virtually,        |                   "Must you shout too?" 
Ned Wolpert       |                                  -Dante
wolpert(at)yahoo(dot)com |             
_________________/              "Who watches the watchmen?"
4e75                                       -Juvenal, 120 AD

-- Place your commercial here --                      fnord

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

In response to

Responses

pgsql-jdbc by date

Next:From: Ned WolpertDate: 2001-12-09 15:38:40
Subject: Re: JDBC 3.0 / JDK 1.4 build issues
Previous:From: Rene PijlmanDate: 2001-12-09 13:32:41
Subject: Re: JDBC 3.0 / JDK 1.4 build issues

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