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.
Thanks,
David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
