Hm, that has continued to be the proposal I liked best. I thought what
derailed it was the inability to guarantee forward compatibility, that
is when a new consumer depends upon a new API.
For example, let's say you have an interface in release 1:
public MyInterface
{
int method1(int val);
}
Now in release 2 the consumer wants to add a new method:
public MyInterface
{
int method1(int val);
String method2(String val);
}
This is a backward-compatible change but not a forward-compatible
change, because if the new consumer calls method2 on the original
MyInterface, he'll get an error.
You could argue this is solvable by saying any modifications to an
interface require a new interface:
public MyInterface2 extends MyInterface
{
int method2(String val);
}
This is both backward- and forward-compatible.
The problem with this is the jar sealing problem. If the old jar is
first in the classpath, then MyInterface will be loaded from the old jar
and MyInterface2 will be loaded from the new jar. If these interfaces
are in the same package (org.apache.derby.common) then you'll get a
SecurityException.
I don't think that Java solves this particular problem, as it generally
assumes you have only one version in your classpath at a given time.
That's what I think has continued to derail any solution we propose.
Thus my proposal to rename the package, to solve the jar sealing problem.
David
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Think of the carnage if it was java_14208_b13.sql_300.Connection
It's actually instructive to look how Java solves this:
- The interface is kept upwards compatible, by following rules such as
only new methods/fields etc.
Then to look at how a consumer, Derby, deals with the fact of multiple
versions of the interface:
- Derby only provides and uses the functionality to match the version of
the interface (java.sql.Connection) loaded, determined at runtime.
I'd thought this was a workable direction being proposed about six
thousand message ago, upwards compatible apis and the ability for a
consumer to handle a lower version. Not sure what derailed it.
Dan.
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
