Re: JDBC 3.0 / JDK 1.4 build issues - Mailing list pgsql-jdbc
From | p@netoides.com |
---|---|
Subject | Re: JDBC 3.0 / JDK 1.4 build issues |
Date | |
Msg-id | 3C174E47.396029A1@netoides.com Whole thread Raw |
In response to | Re: JDBC 3.0 / JDK 1.4 build issues (Rene Pijlman <rene@lab.applinet.nl>) |
List | pgsql-jdbc |
Hello. This idea only works if jdbc2.0 is a subset of jdbc3.0: trying to put all jdbc 3.0 functionality in the jdbc 2.0 driver. The only reason why a jdbc3.0 driver doesn't work with jdbc2.0 is because jdbc2.0 lacks some interfaces/classes. But we could put this extra classes in a postgresql-2.0path.jar This way, there would be only one driver (postgresql.jar for jdbc3.0) and a patch for 2.0 with all the extra interfaces/classes/exceptions in jdbc3.0. Barry Lind wrote: > > Rene, > > I think you have the right idea here. I might suggest that you have an > abstract Connection3 to make things consistent. The only hard part is > to make sure that right classes get built for each driver version. > > thanks, > --Barry > > Rene Pijlman wrote: > > > 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> > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
pgsql-jdbc by date: