Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434AB5A5.3020504@debrunners.com>
Date: Mon, 10 Oct 2005 11:40:37 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: conflict between Derby API and JDBC 4.0
References: <434AB0DB.5000503@sun.com>
In-Reply-To: <434AB0DB.5000503@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.