db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 22:48:35 GMT
Rick Hillegas wrote:

> Thanks, Kathey. I still don't understand the scenario you're
> describing. It seems to me that application A never saw the bug fix at
> all because the shared code was always shadowed by the version which
> application B needed. 

Because for 10.1 there is no shared code, the Application B 10.1 
derby.jar and the Application A 10.2 derbyclient.jar were able to
coexist totally independently.    Upgrading Application B to 10.2 with
the shared code caused the regression in Application A.    It is a very
subtle trap but very dramatic in its effect.

> It's worth pointing out that this problem already exists today:
It is true that there  are problems in this regard today with multiple
embedded apps or multiple client apps.   There is almost always a jar
mixing issue in the support  queue for jar conflicts and they are
ugly.      The one  we are working on right now (with an older version
of Cloudscape) is not just a matter of let's find all the duplicate
jars  we can and replace them,  but includes  necessary patches to some
of the products involved.   I personally am not keen on exacerbating the
problem.  That's perhaps just selfishness because I get to deal with it
all the time, but  I hope you can agree that  the scope of user impact
in the proposal is incorrect.  It should be clear that we are regressing
the ability to mix  the client and server jars. 


View raw message