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 04:43:32 GMT
Thanks for writing up a proposed solution, I was getting a little tired 
of putting up targets for others to shoot down.

I agree with this wholeheartedly this was what I have wanted to do 
(although perhaps not as well communicated and there are some details 
here that are new and which seem really good/interesting).

You say Java does this -- is this documented somewhere? I'd love to have 
that as a reference.

First of all, Kathey was concerned we wouldn't be able to follow this 
kind of discipline.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c43207ABC.8080000@sbcglobal.net%3e

But I'll also show where I saw this get tripped up:

 > * 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)


In my original proposal:

    * compatibility will be strongly encouraged but not guaranteed
      against previous minor versions (e.g. a 10.2 consumer works
      with 10.1 common classes, but a 10.3 consumer has a hard
      dependency on new methods, it can not work with 10.2
      common classes).

Perhaps I remember incorrectly, but I remember us (or enough of us) 
generally agreeing that gracefully dying when Y level function was 
required was not acceptable, as this was a regression of existing 
behavior.  This was the "nail in the coffin" for my original proposal.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c43289F58.6000707@mtrad.com%3e
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/%3c4328AC1F.6000504@sun.com%3e

Unless you can address these issues I think we're back at square one...

David

Further asides below:

> 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)

That's nice to know, I didn't know that

> * 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 don't know much about such frameworks and tools, but I don't think 
this solves Dan's problem of "accidentally" loading multiple versions.

> I think we can support a scenario where:
> * a comsumer expecting version X.Y will work with any implementation
>   X.Y' when Y' >= Y



> * 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