db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 21 Sep 2005 04:24:04 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.
> 

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

Mime
View raw message