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. I would like to restart the discussion by
proposing the following:
1) Derby's public API will contain two sets of DataSource
implementations, one which satisfies the JDBC3 contract and one which
satisfies JDBC4.
2) The documented, approved way to obtain DataSources will be to call
factory methods on EmbeddedDriver and ClientDriver. These factory
methods will hand back either JDBC3 or JDBC4 DataSources depending on
the vm.
3) JDBC4 DataSources will have private constructors.
4) In contrast, the JDBC3 DataSources will continue to expose public
constructors. Existing Derby applications won't have to change, provided
that they are run on jdk1.3, jdk1.4, or jdk1.5.
5) However, we will raise exceptions if applications try to construct
JDBC3 DataSources while running on jdk1.6. The exceptions will tell the
customer to call the appropriate factory methods.
Note that this describes the behavior of Derby 10.2. We make no promises
about what will happen if the customer tries to run earlier versions of
Derby on jdk1.6. Under those combinations, the customer will see runtime
exceptions when trying to invoke JDBC4-specific methods.
Please let me know what you think.
Thanks,
-Rick
Rick Hillegas wrote:
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.
