db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Mortazavi" <Masood.Mortaz...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 21 Sep 2005 06:27:30 GMT
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.

I'm not sure if this will help or hinder with your considerations but . . .

Compatible type evolution is described in the Java Serialization Spec. 
The reason it is described there is because the problem arises when 
Class A is compiled against a particular version of Class B but then at 
run-time an instance of A encounters (through class loading upon 
de-serialization, for example) an instance of some other version of 
Class B.

These type compatibility rules can be found here: 


M. Mortazavi
+1 408 276 7205 (office)
+1 408 421 4093 (mobile)

View raw message