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.
Thanks,
David
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?
No.
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).
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
