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 22:47:08 GMT
I'm afraid I was too elliptical in my first attempt to describe this 
problem. Here's my next attempt:

Suppose that we have a class common.A with encode() and decode() 
methods. In 10.1 and 10.2, these methods have identical signatures but 
implementations which differ so that the 10.1 decode() does not invert 
the 10.2 encode().

Now let's mix a 10.1 client with a 10.2 server in the same VM.

If we don't clone the code, then encode() and decode() will invert one 
another regardless of how we wire 10.1 and 10.2 jars together in the 

However, suppose we clone the code to arrive at client.common.A and 
server.common.A. Suppose further that the client jar, reasonably, does 
not contain server classes and vice versa. In this case, the client's 
decode() will not invert the server's encode(). Somehow, we need to 
detect this incompatibility.

The point I am trying to make is this: It seemed to me that code cloning 
was put forward as an alternative to the compatiblity checking in 
David's first proposal. I don't think cloning solves this problem. It 
merely pushes the problem around a bit. We still need run-time 
compatibility checking.


Daniel John Debrunner wrote:

>Rick Hillegas wrote:
>>I would like to add a few comments to this very useful discussion:
>>(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.
>Not sure what point you are making here, how does copying the code into
>different packages change its behaviour?
>With what ever approach, if the client is at version X and the
>engine/network server at version Y then by definition the common code
>will be different. Could be the same api, but maybe bug fixes in Y that
>don't exist in X.

View raw message