db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 16:53:00 GMT
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 



> Cheers,
> -Rick

View raw message