db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 22:01:17 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. However, the following scenario could occur and might be akin to
> the problem which is troubling you:
> 
> o Two applications, EmbeddedApp and ClientServerApp run in the same VM.
> 
> o EmbeddedApp contains derby.jar(rev 1)
> 
> o ClientServerApp contains derbyclient.jar(rev 3)
> 
> o classpath=EmbeddedApp;ClientServerApp
> 
> o ClientServerApp wants an important bug fix in shared code available in
> Derby rev 4. However, after upgrading to derbyclient.jar(rev 4),
> ClientServerApp still can't enjoy the bugfix because the improved shared
> code is shadowd by the old, buggy version in EmbeddedApp. The only way
> that ClientServerApp can enjoy this bugfix is if EmbeddedApp upgrades to
> use derby.jar(rev 4).
> 
> It's worth pointing out that this problem already exists today:
> 
> o Two applications, ClientServerApp1 and ClientServerApp2 run in the
> same VM.
> 
> o ClientServerApp1 contains derbyclient.jar(rev 1)
> 
> o ClientServerApp2 contains derbyclient.jar(rev 3)

Well, you did a sneaky switch to two versions of the client jar!

The problem does not exist today if you had kept the example the same
(derby.jar and derbyclient.jar) and shared code did not exist.

I don't think anyone is saying that shared code has to fix every
mismatch, but the real point is, do we want to (potentially) regress in
this area?

Dan.


Mime
View raw message