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.
>
>Dan.
>  
>

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: 
http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp9419

M.

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



Mime
View raw message