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 22:16:55 GMT
So, I'll wait for another overnight (over-day) period, but it sounds 
like we may have a level of consensus here (fingers crossed).

What I propose to do is take Jeremy's quick brain dump (thanks again for 
doing this Jeremy) and turn it into a more complete policy around this. 
  Hopefully I'll capture the essence of this correctly, but I'm sure 
you'll correct me if I miss something :)

I'll put this on the Derby Wiki, to make it more readable/reviewable.

Thanks all,


Jeremy Boynes wrote:
> 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.
> Kathey asked if I would be willing to write something up and I started 
> thinking about it but haven't had the bandwidth to write anything.
> As a quick braindump:
> * there are rules that restrict changes to the interface going forward
> * Sun (et al) stick to those rules even when it is painful
> * no class/method is removed without being deprecated first
> * the JVM supports version skew a little by not requiring an
>   implementation to implement all methods in a interface (at runtime)
> * the interfaces often provide a mechanism to determine what features of
>   an API the implementation implements
> * frameworks can utilize multiple classloaders to load multiple versions
>   of a class into the VM - tools have developed to simplify this
> I think we can support a scenario where:
> * a comsumer expecting version X.Y will work with any implementation
>   X.Y' when Y' >= Y
> * a consumer expecting X.Y will work with X.Y' when Y' < Y by version
>   detection and degraded functionality (Y' level). If Y level function
>   is required then it will gracefully die (able to detect rather
>   than AbstractMethodError)
> * X.Y defines the interface version, i.e. X.Y.Z works with X.Y.Z' for
>   all Z'
> * X defines the compatibility level i.e. X and X' are not guaranteed
>   to work together (although we will try to ensure they do)
> Basic rules:
> * at the Z level, no API change is allowed, just implementation changes
> * at the Y level, additive API changes are allowed but must be
>   accompanied by support in the versioning mechanism so that they can be
>   detected. Things can be deprecated
> * at the Z level, incompatible changes are allowed. Items deprecated in
>   version X can be removed in version X+2 (implicitly (X+2).0.0).
> This all applies to operation in a single classloader. Where multiple 
> classloaders are involved (inside one VM or in multiple VMs) a different 
> set of versioning behaviours applies to the wire protocol.
> -- 
> Jeremy

View raw message