Rick Hillegas wrote: > Thanks to everyone who responded to the proposal I circulated earlier > this week. I will attempt to recap the discussion: > > o JDBC3 DataSources do not satisfy the contract for JDBC4. > o Loading a JDBC4 DataSource into a 1.4 VM raises > java.lang.UnsupportedClassVersionError. David and I are scared by the > suggestion that we fiddle the byte code of the JDBC4 DataSources to > trick the 1.4 VM. > o App servers will break under my proposal to move DataSource > instantiation into factory methods. This is because app servers declare > the DataSource classes in ConnectionPool settings and so expect > DataSources to have public, no-arg constructors. > > Here is a new, simpler proposal: > > o 10.2 will ship with two sets of DataSources, one for JDBC3 and one for > JDBC4. > o The user documentation will advise customers to use VM-appropriate > DataSources. > o Existing Derby apps will continue to work on the 1.6 VM. > o Customers will have to recode their existing Derby applications if > they want to invoke new JDBC4 methods. That is, the applications will > have to instantiate JDBC4 DataSources rather than JDBC3 DataSources.
I agree with the general thoughts above, but I belive the details are a little different. > o 10.2 will ship with two sets of DataSources, one for JDBC3 and one for > JDBC4. The "JDBC 3.0" DataSource implementations themselves will not implement the JDBC 4.0 contract for javax.sql.DataSource, ConnectionPoolDataSource and XADataSource, but Connection objects returned from them will honour the JDBC 4.0 Connection contract. > o Customers will have to recode their existing Derby applications if > they want to invoke new JDBC4 methods. That is, the applications will > have to instantiate JDBC4 DataSources rather than JDBC3 DataSources. Append "on the DataSource interfaces" after "invoke new JDBC4 methods". Dan.
