Hi, Rick.
Rick Hillegas wrote:
I would like to add a few comments to this very useful discussion:
(1) The question was raised: why do we want to share code in the
first place? For me, the big issue is the brittleness of code cloning.
Over time, cloned code diverges--I don't know of any bullet-proof
process for preventing this. Over time, the assumptions in the cloned
code will diverge. If you are lucky, this will surface as exceptions.
If you're not lucky, this will surface silently in very tricky bugs.
This issue just gets bigger as the Derby developer community grows and
is particularly important for our under-tested network layer.
yes, agreed
(2) A possible solution was raised: instead of cloning the code in the
source tree, clone it during the build process. I have written similar
kinds of ant-based code pre-processors and can give some advice if we
adopt this approach. Done right, it's a pleasant afternoon's work.
However, I have reservations about this approach. It seems to me that
it subverts the meaning of "common" code. To me "common" means
"behaves the same way." It's not just a matter of preserving APIs that
the compiler can check. It comes down to actually doing the same thing
internally. As an example, consider a pair of encoding/decoding
methods. You want the internal encoding/decoding logic to be the same
everywhere. I don't think that build-time cloning saves us from the
problem of having to do a run-time compatibility check.
I'm a bit confused. The code *is and always will be* exactly the same.
Were you thinking we'd clone and then diverge? It really is common code
-- it's not just preserving APIs. The cloned code can not be modified,
it can only be modified from the original source. I am concerned I'm
missing your point :)
(3) Concerning the packaging of common code: I'm a big fan of
duplicating the classes in the client and server jars. I would like to
keep the "out of box" experience simple for users who are new to Derby
or even new to Java. Our "0 administration" story is arguably our most
compelling differentiator.
Yes, this message appears to be loud and clear -- duplicate the classes
in client and server jars. This becomes even more the right thing to do
if we adopt code cloning.
(4) Concerning the specifics of David's proposal: I think that
checkCommonCompatibility() would be easier to use if the second
argument were firstCompatibleVersion rather than
firstIncompatibleVersion. It seemed to me that the
secondIncompatibleVersion number should be less than the
firstIncompatibleVersionNumber and I always get muddled when 2 < 1.
Good point. If we find ourselves going back to that approach (my sense
is the consensus is moving towards cloning) then I think this is a good
adjustment.
Thanks,
David
Cheers,
-Rick
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
