db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 15:54:04 GMT
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.

(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.

(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.

(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.

Cheers,
-Rick

Mime
View raw message