db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 21 Sep 2005 03:54:55 GMT
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.
> 
> 
> 
> 

Mime
View raw message