db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: conflict between Derby API and JDBC 4.0
Date Wed, 25 Jan 2006 01:13:45 GMT
Rick Hillegas wrote:

> Three months ago, we shelved this topic, promising to return to it
> later. I would like to reach consensus on this problem now. In a
> nutshell: JDBC4 introduces new methods whose signatures contain
> generics. 

Are generics represented by new entries in the class file that break on
older VMs?

> Because of this, DataSource implementations can't satisfy both
> the JDBC3 and JDBC4 contracts. I would like to restart the discussion by
> proposing the following:
> 1) Derby's public API will contain two sets of DataSource
> implementations, one which satisfies the JDBC3 contract and one which
> satisfies JDBC4.
> 2) The documented, approved way to obtain DataSources will be to call
> factory methods on EmbeddedDriver and ClientDriver. These factory
> methods will hand back either JDBC3 or JDBC4 DataSources depending on
> the vm.

-1 Breaks the established pattern of how DataSource objects are used.

> 3) JDBC4 DataSources will have private constructors.

-1 Breaks the established pattern of how DataSource objects are used.

> 4) In contrast, the JDBC3 DataSources will continue to expose public
> constructors. Existing Derby applications won't have to change,

> provided that they are run on jdk1.3, jdk1.4, or jdk1.5.

-1 Much like I expect a application written against JDK 1.4 to run on
JDK 1.5, shouldn't I expect an application written against JDK 1.4 to
run on 1.6? Or is there some change in Java binary compatibility I'm
unaware of?

> 5) However, we will raise exceptions if applications try to construct
> JDBC3 DataSources while running on jdk1.6. The exceptions will tell the
> customer to call the appropriate factory methods.

-1 JDBC 3.0 DataSources/applications should work fine on JDK 1.6/JDBC
4.0. Again, unless Java binary compatibility is broken.

> Note that this describes the behavior of Derby 10.2. We make no promises
> about what will happen if the customer tries to run earlier versions of
> Derby on jdk1.6. Under those combinations, the customer will see runtime
> exceptions when trying to invoke JDBC4-specific methods.

I agree with this, Derby 10.0 and 10.1 do not support JDBC 4.0, so
calling JDBC 4.0 methods against their drivers/data sources etc. will
lead to abstract method exceptions or similar.


View raw message