David W. Van Couvering wrote:
Hi, all. Yes, it's your favorite topic. :)
I've been thinking about this further, and I would like to say that
it's time to bite the bullet and address this. I am planning on
piloting this with the i18n work so that I can reuse the
message.properties file rather than duplicate error messages. I am
sure other uses will quickly follow.
I talked with Craig Russell today, and he had some very helpful advice
for an approach to common code. It is based on employing engineering
discipline and policies around shared code.
The basic principle is you have full backward compatibility. Each new
revision of shared code has behavior and interfaces that are fully
backward-compatible with older revisions. Here is my proposal on how
this is implemented. After some discussion, I'd like to put this up
for a vote.
- An "interface" is defined as anything externally visible that is or
may be depended upon by subsystems outside of the common packages.
This is not just a Java interface, but any method, constant, variable,
class name, package name, etc., that is externally accessible.
- All common interfaces are guaranteed to work as defined in all
subsequent releases of Derby. This means you can't for instance keep
the same method signature but rewrite its behavior. - If you want to
introduce a new revision of an interface (e.g. new arguments or new
behavior), you do not modify or remove the old interface. You instead
create a completely new revision. For example, if you have a method
doIt(int a), then the new version would be doIt_2(int a) or doIt(int
a, String b)
- If an interface needs to be deprecated, it is documented as
deprecated and is removed in the next major release (e.g if it's
deprecated in 10.2, it can be removed in 11.0). This should be
avoided if at all possible
The common classes will be placed into both derby.jar and
derbyclient.jar. When you have a classpath with a network client at
one revision and the embedded driver at another revision, the jar with
the highest revision should always go first, e.g
"/home/derby/10.2/derbyclient.jar:/home/derby/10.1/derby.jar". This
ensures that the newer code that depends on new interfaces (e.g. a new
method for a class) will be able to function properly.
Hi David,
I do not believe you can enforce this if you are you the lib ext dir
model which would make this problematic for a J2EE environment.
Regards
Lance
Thanks,
David
