Re: conflict between Derby API and JDBC 4.0

[Lance J. Andersen]

Daniel John Debrunner wrote: 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. Because of this, DataSource implementations can't satisfy both the JDBC3 and JDBC4 contracts. So that's not quite true, a JDBC 4.0 DataSource implementation does satisfy both JDBC 4.0 and JDBC 3.0. I've been looking at if it would be possible to have a single implementation that worked in both. Ie. would the reference to new classes and the generics absolutely make the class not work in JDBC 3.0. Most likely yes, but it's worth throwing out there. One question I do have on the JDBC 4.0 spec, is what is the purpose of this method in javax.sql.DataSource? <T> T createQueryObject(java.lang.Class<T> ifc) throws SQLException For some reason it's not seen as required for a ConnectionPoolDataSource or an XADataSource, so why is it needed on DataSource? This is there as an EoD feature for Java EE developers.  Java EE apps deal with DataSources not usually directly with XADataSources or ConnectionPoolDataSources. DataSets layer Rowsets and ResultSets.  RowSets already accept a DataSource instead of a Connection object. Often a DataSource is typically implemented by application server. Application server's implementation of DataSource will implement the createQueryObject method. That will  result in a call  such as        return underlyingDataSource.getQueryObjectGenerator().createQueryObject(ifc, this); As far as I can tell it seems to be a short-cut for getConnection().createQueryObject(java.lang.Class<T> ifc) (using the getConnection() method on javax.sql.DataSource). Should we ask this question to the JDBC 4.0 review? The whole ease of section 20.1 in JDBC 4.0 I'd assumed would be above the level of the JDBC driver, it's somewhat disconcerting to me that it's that closely linked to the low level driver. Related to that, does anyone have any idea how the QueryObjectGenerator interface is meant to be used. What piece of code would call CommonDataSource.getQueryObjectGenerator()? Would it be a wrapping DataSource implementation (e.g. from a app server). Section 20.1.6 seems to be no help here. Section 20.2.2.1 has this sentence: "If the JDBC driver does not provide its own implementation of a QueryObjectGenerator, it must invoke the default QueryObjectGenerator implementation provided by Java SE 6." I can't see any mention of how a driver implementation finds the defaultQueryObjectGenerator implementation. Dan.