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, 14 Sep 2005 23:02:55 GMT
Ah, I see, yes, you have a point.  Well, big swallow, it seems to me 
that this is indeed a regression, and a potential usability headache.

Thinking further, this same issue exists for any platform where shared 
code can come in through many fronts.  I was once told that one 
distribution of Linux had three or four different copies of Berkeley 
DB.  I guess the difference here is that shared libraries are versioned 
and you can load a .so of a specific version if you need to, while you 
can not do this with JAR files.

Unless someone can convince me otherwise, I am going to have to switch 
boats and back Approach 2, the Common Clone approach.  I can hold my 
architectural purity nose while writing the cloning code.



Daniel John Debrunner wrote:

>David W. Van Couvering wrote:
>>Note that the main reason these customers want to run with different
>>versions, as I understand it, is so that they can run with a version of
>>the client that matches the server version.  If we can guarantee
>>compatibility between client and server versions (so, for instance, you
>>can upgrade the server without having to upgrade the clients, or vise
>>versa), does this requirement goes away? 
>Client/server compatibility is good, and soft upgrade is good, and all
>help in the area of reducing version compatibility problems.
>But I'm not saying anyone *wants* to mix versions, rather that they end
>up mixing versions through circumstances.
>I'm assuming worst case, end-user A knows nothing about Java, and is
>using applications from vendor B (client at version 10.2) and vendor C
>(engine at version 10.3).

View raw message