Hi, Rick. You had my vote, item 3 (although I don't understand how it
would change our public API, I didn't know EmbeddedDataSource was a
public (e.g. for-customer-use) API).
I would suggest proposing what you think is the best solution and I
suspect you'll get some feedback. If you don't, you can assume lazy
consensus and do what you think is best (although I suspect you *will*
get some feedback :) ).
David
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?
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.
3) Change our public API.
I would appreciate some discussion of this serious problem.
Thanks,
-Rick
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
