Обсуждение: JDBC 3.0 / JDK 1.4 build issues
I'm working on a patch which enables the driver to compile with JDBC 3.0 / JDK 1.4 (currently beta-3). Basically we need to add a few methods and throw "not implemented" in most of them. Unfortunately, when the driver is modified to compile with JDK 1.4, it won't compile with JDK 1.3 and older. There are at least two reasons for this: 1) Connection must implement the new method setSavePoint(), which returns a new type java.sql.Savepoint See: http://java.sun.com/j2se/1.4/docs/api/java/sql/Connection.html#setSavepoint( ) http://java.sun.com/j2se/1.4/docs/api/java/sql/Savepoint.html 2) PreparedStatement must implement the new method getParameterMetaData(), which returns a new type java.sql.ParameterMetaData See: http://java.sun.com/j2se/1.4/docs/api/java/sql/PreparedStatement.html#getPar ameterMetaData() http://java.sun.com/j2se/1.4/docs/api/java/sql/ParameterMetaData.html I think its very undesirable to fork the entire jdbc2 driver, just to be able to add a couple of methods which throw "not implemented". In fact, I find the current situation with jdbc1/jdbc2 too cumbersome already. It seems the only alternative is some sort of conditional compilation using make or ant. Any ideas? In case someone wants to have a look, I've attached a patch which makes the driver in current CVS compile with JDK 1.4b3. With this patch applied, the driver _won't_ compile with JDK 1.3.x and older. Use at own risk :-) Cheers, René Pijlman <rene@lab.applinet.nl>
Вложения
--- Rene Pijlman <rene@lab.applinet.nl> wrote: > Unfortunately, when the driver is modified to compile with JDK 1.4, it > won't compile with JDK 1.3 and older. There are at least two reasons for > this: > > 1) Connection must implement the new method setSavePoint(), which > returns a > new type java.sql.Savepoint 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? (We may not need much more ant-processing since it still called java.sql.Connection.) It does seem similiar to jdbc1 -> jdbc2 issues. (See end of email for more on this...) > 2) PreparedStatement must implement the new method > getParameterMetaData(), which returns a new type > java.sql.ParameterMetaData Same thing here. Getting a PreparedStatement comming from the jdbc3 Connection would return this. Also, we'll need a new CallableStatement since it extends PreparedStatement. Our new callable one needs to extend the jdbc3 one. > I think its very undesirable to fork the entire jdbc2 driver, just to be I agree. I don't think we have to. But if we compile with jdk1.4, we cannot compile the jdbc2 or jdbc1 stuff. That's the only real issue to me, so far. Though this is kinda distressing since Sun could have easilly made a java.sql.jdbc3.Connection internface themselves that would implement the new method. This means that our current driver cannot compile at all in jdk1.4. Is that correct? That sucks. ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante wolpert@yahoo.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
--- Rene Pijlman <rene@lab.applinet.nl> wrote: > Unfortunately, when the driver is modified to compile with JDK 1.4, it > won't compile with JDK 1.3 and older. There are at least two reasons for > this: > > 1) Connection must implement the new method setSavePoint(), which > returns a > new type java.sql.Savepoint 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? (We may not need much more ant-processing since it still called java.sql.Connection.) It does seem similiar to jdbc1 -> jdbc2 issues. (See end of email for more on this...) > 2) PreparedStatement must implement the new method > getParameterMetaData(), which returns a new type > java.sql.ParameterMetaData Same thing here. Getting a PreparedStatement comming from the jdbc3 Connection would return this. Also, we'll need a new CallableStatement since it extends PreparedStatement. Our new callable one needs to extend the jdbc3 one. > I think its very undesirable to fork the entire jdbc2 driver, just to be I agree. I don't think we have to. But if we compile with jdk1.4, we cannot compile the jdbc2 or jdbc1 stuff. That's the only real issue to me, so far. Though this is kinda distressing since Sun could have easilly made a java.sql.jdbc3.Connection internface themselves that would implement the new method. This means that our current driver cannot compile at all in jdk1.4. Is that correct? That sucks. ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante wolpert@yahoo.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
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? >(We may not need much more ant-processing since it still called >java.sql.Connection.) It does seem similiar to jdbc1 -> jdbc2 issues. OK, that may do the trick. But why is for example jdbc2/DatabaseMetaData.java a copy of jdbc1/DatabaseMetaData.java? Why isn't this done with inheritance to only add new methods in jdbc2? It seems to be the same for PreparedStatement, ResultSet etc. I see lots of duplicate code. Or am I missing something? >This means that our current driver cannot compile at all in jdk1.4. Indeed. Some interfaces require new methods. And some of these methods require types which are only available in the new version of the interfaces. Regards, René Pijlman <rene@lab.applinet.nl>
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? It would still be: package org.postgresql.jdbc2; public class Connection extends org.postgresql.Connection implements java.sql.Connection Right? And that class won't compile with JDK 1.4 since it lacks new methods like setHoldability() of the java.sql.Connection interface. This raises a compile time error "class should be declared abstract...". And if we change the definition of this class to not implement java.sql.Connection, then the same code won't produce a proper implementation of JDBC2 with a JDK <= 1.3. 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. Regards, René Pijlman <rene@lab.applinet.nl>
--- Rene Pijlman <rene@lab.applinet.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@yahoo.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
--- Rene Pijlman <rene@lab.applinet.nl> wrote: > OK, that may do the trick. But why is for example > jdbc2/DatabaseMetaData.java a copy of > jdbc1/DatabaseMetaData.java? Why isn't this done with > inheritance to only add new methods in jdbc2? > > It seems to be the same for PreparedStatement, ResultSet etc. I > see lots of duplicate code. Or am I missing something? We may have more duplicated code then desired. I can't explain about the DatabaseMetaData stuff, if it could have been inherited or had to be 'forked'. I'm sure that going from jdbc1 -> jdbc2 some classes could not be inherited, like the case of the Connection class in jdbc3. But if all those classes didn't need to be forked for jdbc1->jdbc2, perhaps it was done to simplify making changes. (making jdbc2 changes, that is.) Of course, by doing this we have a problem of making changes in both packages when a new bug is found. This is why I like inheritance when possible, versus forking. ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante wolpert@yahoo.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
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>
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 > >
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
On Mon, 10 Dec 2001 21:18:27 -0800, you wrote: >The only hard part is to make sure that right classes >get built for each driver version. I didn't follow the make vs. ant discussion very closely. Did it reach a conclusion or some sort of consensus on the preferred build tool? Regards, René Pijlman <rene@lab.applinet.nl>
Rene, We are going to support both for now. Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Rene Pijlman Sent: Friday, December 14, 2001 12:25 PM To: Barry Lind Cc: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] JDBC 3.0 / JDK 1.4 build issues On Mon, 10 Dec 2001 21:18:27 -0800, you wrote: >The only hard part is to make sure that right classes >get built for each driver version. I didn't follow the make vs. ant discussion very closely. Did it reach a conclusion or some sort of consensus on the preferred build tool? Regards, René Pijlman <rene@lab.applinet.nl> ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
> Rene, > > We are going to support both for now. Right now we support only Ant, not Make, right? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Well sort of... We are using make to start ant, but we are using the ant build file to build the jars -----Original Message----- From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] Sent: Saturday, December 15, 2001 1:01 PM To: Dave@micro-automation.net Cc: 'Rene Pijlman'; 'Barry Lind'; pgsql-jdbc@postgresql.org Subject: Re: [JDBC] JDBC 3.0 / JDK 1.4 build issues > Rene, > > We are going to support both for now. Right now we support only Ant, not Make, right? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, 15 Dec 2001 15:16:49 -0500, you wrote: >Well sort of... >We are using make to start ant, but we are using the ant >build file to build the jars But is the plan to also enable building the driver without ant installed? Regards, René Pijlman <rene@lab.applinet.nl>
> On Sat, 15 Dec 2001 15:16:49 -0500, you wrote: > >Well sort of... > >We are using make to start ant, but we are using the ant > >build file to build the jars > > But is the plan to also enable building the driver without ant > installed? That is what has me confused about allowing both Ant and Make. I guess he was just saying we stay with our current make calls ant setup. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Rene, Dave and I exchanged a few emails on this a while back, and I think what we decided on was that we would support both make and ant independently in 7.3. That means two independant methods of building the code, makefiles that don't depend on ant, and ant that doesn't depend on make calling it. Both build mechanisms have their pros and cons as was born out in the long email thread on this topic a few weeks ago. I agreed to work on/support the make build method and Dave agreed to support the ant one. thanks, --Barry Rene Pijlman wrote: > On Sat, 15 Dec 2001 15:16:49 -0500, you wrote: > >>Well sort of... >>We are using make to start ant, but we are using the ant >>build file to build the jars >> > > But is the plan to also enable building the driver without ant > installed? > > Regards, > René Pijlman <rene@lab.applinet.nl> >
Barry Lind wrote:
> Rene,
>
> Dave and I exchanged a few emails on this a while back, and I think what
> we decided on was that we would support both make and ant independently
> in 7.3. That means two independant methods of building the code,
> makefiles that don't depend on ant, and ant that doesn't depend on make
> calling it. Both build mechanisms have their pros and cons as was born
> out in the long email thread on this topic a few weeks ago. I agreed to
> work on/support the make build method and Dave agreed to support the ant
> one.
TODO updated:
JDBC
o Support both 'make' and 'ant'
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Thu, 3 Jan 2002 00:48:05 -0500 (EST), you wrote: >TODO updated: > > JDBC > o Support both 'make' and 'ant' You may want to add "Support build with JDK 1.4 / JDBC 3.0 (without code duplication)". I'm still working on it. Regards, René Pijlman <rene@lab.applinet.nl>