Sorry, Lance, I am assuming you mean I can't enforce classpath order.
Yes, Dan has also made that point, thanks.
David
Lance J. Andersen wrote:
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
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
