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
reference?
Thanks,
-Rick
Knut Anders Hatlen wrote:
Hi,
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
EmbeddedDataSource.
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.
