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, +1 > 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. Dan.
