Thanks, Dan. For the record, I think that this affects
org.apache.derby.jdbc as follows:
- ClientConnectionPoolDataSource (implements
javax.sql.ConnectionPoolDataSource, which extends
javax.sql.CommonDataSource, which mentions QueryObjectGenerator, which
is new to 1.6 and mentions generics).
- ClientDataSource (implements javax.sql.DataSource, which mentions
generics)
- ClientXADataSource (same as ClientDataSource)
- EmbeddedConnectionPoolDataSource (same as ClientDataSource)
- EmbeddedDataSource (same as ClientDataSource)
- EmbeddedSimpleDataSource (same as ClientDataSource)
- EmbeddedXADataSource (same as ClientDataSource)
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I would like advice on how to handle the conflict between the public
Derby API and JDBC 4.0. This issue was raised by Dan in his comments on
bug 587.
A) Does this issue block the submission of the 587 fix?
I don't think so. But I think we would want to resolve the issue before
release a Derby version that contained this code. Though potentially
resolution could wait until JDBC 4.0 was official.
B) How do we want to handle this conflict in 10.2?
The problem is that some javax.sql interfaces are incompatible between
jdk1.4 and jdk1.6. A class implementing one of these interfaces can't
run on both the 1.4 and 1.6 vms. This is a showstopper for Derby because
i) our public API contains classes which implement these incompatible
interfaces and ii) we ship a single jar which we expect will run on all
supported vms. The comments on bug 587 suggest some solutions:
1) Some, as yet not understood, classloader trick.
2) Abandon requirement (ii) and release separate Derby deployments for
1.4 and 1.6.
I would say 2) is out, it seems overkill for a single class to drive a
switch to multiple/different versions for different environments.
3) Change our public API.
I would appreciate some discussion of this serious problem.
Beyond that, I will think more :-)
Dan.
