db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Are separate JDBC 4.0 versions of the DataSource classes really needed?
Date Mon, 24 Jul 2006 14:56:16 GMT
Hi Knut Anders,

I don't understand part of your experiment. The implementation of 
createQueryObject() refers to another class, QueryObjectFactory, which 
was introduced by JDK 1.6. How did EmbeddedDataSource compile with this 


Knut Anders Hatlen wrote:

>I started looking at our implementation of JDBC 4.0 data sources when
>I saw Rick updating the documentation with information about using
>Embedded*DataSource40 when running jvm>=1.6. I think it is problematic
>to have this split between pre-JDBC4 data sources and JDBC4 data
>sources for a number of reasons:
>  - it is confusing for the users to have thirteen different data
>    source implementations (EmbeddedSimpleDataSource,
>    EmbeddedDataSource, EmbeddedConnectionPoolDataSource,
>    EmbeddedXADataSource, EmbeddedDataSource40,
>    EmbeddedConnectionPoolDataSource40, EmbeddedXADataSource40,
>    ClientDataSource, ClientConnectionPoolDataSource,
>    ClientXADataSource, ClientDataSource40,
>    ClientConnectionPoolDataSource40, ClientXADataSource40)
>  - it is difficult to maintain and document properly
>  - applications that use data sources don't automatically start using
>    JDBC 4.0 when upgrading to Derby 10.2
>  - how should we name the classes when we start implementing JDBC
>    5.0? DataSource40 will be misleading and DataSource50 will only
>    increase the confusion (it would give a total of nineteen classes)
>For the internal implementation classes, this is not a big problem
>since the users don't see their names, but the DataSource classes are
>in our published API and therefore visible to our users.
>The rationale behind adding new classes for the JDBC 4.0 data sources
>was that they contained generic method signatures which wouldn't
>compile under jdk<1.6. The problematic method signatures are
>  <T> T unwrap(Class<T>)
>  <T extends BaseQuery> createQueryObject(Class<T>)
>  <T extends BaseQuery> createQueryObject(Class<T>, DataSource)
>However, the actual signatures of the compiled methods are
>  Object unwrap(Class)
>  BaseQuery createQueryObject(Class)
>  BaseQuery createQueryObject(Class, DataSource)
>I tried to put these methods with modified signatures into
>EmbeddedDataSource and removed them from Embedded*DataSource40. To
>make it compile, I had to modify the build.xml script to add an empty
>java.sql.BaseQuery class to the classpath when compiling
>The conclusion from this experiment was: it compiles, it runs under
>jvm1.6 (jdbc40 suite passed without errors), and it runs under jvm1.3,
>jvm1.4 and jvm1.5.
>Does anyone see any serious problems with this approach? Although it's
>a dirty hack, I think it is much better than shipping a double set of
>data sources.

View raw message