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: Modular build, was: VOTE: Approach for sharing code
Date Tue, 20 Sep 2005 17:37:22 GMT
There are now three cloning proposals for handling shared code:

1) Hand cloning by the developer as is done today.

2) Build-time cloning.

3) Release-time cloning (David's latest proposal).

All of these cloning approaches address Dan's problem case: a client and 
server at diffferent rev levels in the same classpath. It's worth 
pointing out that none of these proposals addresses the other mixed 
usage scenario: wiring into the classpath two applications each of which 
embeds a different version of the server. In that scenario we can still 
expect Heisenbugs. We've never tested this scenario and so we have no 
idea what our current exposure is. I agree with Jeremy that this 
scenario is a systemic defect in Java and that we are not responsible 
for solving it. The best we can do is point our users at best-of-breed 
techniques for containing the problem.

Here's what I think about the cloning proposals:

+ Requires no changes.
- Brittle, bug-prone.
- Can't cut clone bloat by refactoring jar files.

+ Simple for bug porting.
- Can't cut clone bloat by refactoring jar files.
- Awkward to code and debug.

+ Easy to code and debug.
+ Clone bloat not necessary if client and server at same rev level.
- Awkward for bug porting.

In and of themselves, none of these approaches presents the naive 
customer any additional complexity out-of-the-box. Additional complexity 
would vex the customer if, for option (3) we refactored the jar files to 
cut clone bloat. I dislike (3) the least.


View raw message