Thanks to everyone who responded to the proposal I circulated earlier
this week. I will attempt to recap the discussion:
o JDBC3 DataSources do not satisfy the contract for JDBC4.
o Loading a JDBC4 DataSource into a 1.4 VM raises
java.lang.UnsupportedClassVersionError. David and I are scared by the
suggestion that we fiddle the byte code of the JDBC4 DataSources to
trick the 1.4 VM.
o App servers will break under my proposal to move DataSource
instantiation into factory methods. This is because app servers declare
the DataSource classes in ConnectionPool settings and so expect
DataSources to have public, no-arg constructors.
Here is a new, simpler proposal:
o 10.2 will ship with two sets of DataSources, one for JDBC3 and one for
JDBC4.
o The user documentation will advise customers to use VM-appropriate
DataSources.
o Existing Derby apps will continue to work on the 1.6 VM.
o Customers will have to recode their existing Derby applications if
they want to invoke new JDBC4 methods. That is, the applications will
have to instantiate JDBC4 DataSources rather than JDBC3 DataSources.
I appreciate your continued feedback.
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.
