db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Are separate JDBC 4.0 versions of the DataSource classes really needed?
Date Mon, 24 Jul 2006 09:47:10 GMT

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.

Knut Anders

View raw message