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:
(1)
+ Requires no changes.
- Brittle, bug-prone.
- Can't cut clone bloat by refactoring jar files.
(2)
+ Simple for bug porting.
- Can't cut clone bloat by refactoring jar files.
- Awkward to code and debug.
(3)
+ 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.
Cheers,
-Rick
