Well, you did a sneaky switch to two versions of the client jar!
The problem does not exist today if you had kept the example the same
(derby.jar and derbyclient.jar) and shared code did not exist.
Right. This is the small incremental exposure introduced by David's
proposal.
I don't think anyone is saying that shared code has to fix every
mismatch, but the real point is, do we want to (potentially) regress in
this area?
Dan.
Right. David's proposal doesn't claim to fix this problem. And his
proposal does introduce some extra exposure. I'm arguing that the extra
exposure is small compared to the current exposure. I'm also arguing
that the benefits of his proposal are worth this extra exposure.
I hope we're not talking past one another here. It's so easy to do in
email. I think we may agree on the following points:
o There is an existing problem when you mix two Derby-enabled
applications in the same vm.
o David's proposal increases our customer's exposure to this problem.
However, we may part ways on the following points:
o How significant that extra exposure is.
o Whether the benefits of code sharing justify that extra exposure.
Regards,
-Rick
