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 05:51:28 GMT
David W. Van Couvering wrote:
> 
> You say Java does this -- is this documented somewhere? I'd love to have 
> that as a reference.
> 

Do you mean the JVM impl or the general philosophy? I think the 
versioning model is defined in the language spec but would have to go 
digging.

> 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

> 

It is on us and our users to police ourselves.

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

I'd put this as part of the discipline. The Y consumer, as the newer 
version, knows about earlier Y' versions and hence can be coded to 
accept the downrev dependency - it can downgrade itself, it can offer 
different behaviour, it can implement the functionality itself, it can 
die gracefully, or we can just make it X+1.

Bear in mind there are no guarantees. For example, someone else could 
have modified Y' themselves without any regard to compatibility and just 
stuck it on the classpath.

Also, let's not forget that this is only in the case where we have 
multiple applications with poor classpath discipline installed 
concurrently. (And I haven't forgotten the request for a writeup on 
stuff like ClassWorlds).

--
Jeremy

Mime
View raw message