Re: JDBC 3.0 / JDK 1.4 build issues

Поиск
Список
Период
Сортировка
Искать
От
Rene Pijlman
Тема
Re: JDBC 3.0 / JDK 1.4 build issues
Дата
Msg-id
nep61usnapgmmlo6q7orjt1ccn528444fc@4ax.com
Ответ на
Список
Дерево обсуждения
JDBC 3.0 / JDK 1.4 build issues "Rene Pijlman" <rene@lab.applinet.nl>
Re: JDBC 3.0 / JDK 1.4 build issues Ned Wolpert <wolpert@yahoo.com>
Re: JDBC 3.0 / JDK 1.4 build issues Rene Pijlman <rene@lab.applinet.nl>
Re: JDBC 3.0 / JDK 1.4 build issues Ned Wolpert <wolpert@yahoo.com>
Re: JDBC 3.0 / JDK 1.4 build issues Rene Pijlman <rene@lab.applinet.nl>
Re: JDBC 3.0 / JDK 1.4 build issues Ned Wolpert <wolpert@yahoo.com>
Re: JDBC 3.0 / JDK 1.4 build issues Rene 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 
В списке pgsql-jdbc по дате отправления
От: Rene Pijlman
Дата:
От: Ned Wolpert
Дата:
FAQ