This is correct, except I think limiting it to "classpath" may cause
confusion in some environments. See for example Bryan's struggles
because he had a Derby jar file in $JAVA_HOME/lib/ext, which takes
precedence over the classpath.
You might say something more general like "ensuring that the higher
revision level jar is first in the order that classes are loaded (e.g.
by placing it first in the classpath) will make the functionality and
bugfixes from the higher revision level available"
Also, it's possible that the higher revision functionality is still
visible *if* it's from a package that doesn't exist in the older
revision of the common code. For example, if you add
org.apache.derby.common.foobar to revision 1234 and this package is not
in revision 1233, then the classes in foobar will be visible regardless
of classpath ordering. This is *not* the case if you add new classes to
an existing package, as classes for a given package can not be loaded
from multiple jar files if the packages are sealed (which I'm assuming
is the case for common packages). Do I have that right?
Also, you don't talk about upgrade scenarios, where the bugfix is there,
but then someone upgrades and all of a sudden the bugfix is gone. This
can *only* occur if (a) the bug fix is in a new package and thus visible
even though the jar file doesn't have precedence and then (b) the
upgrade places the jar file with most precedence at a revision level
that has the new package but *not* with the bugfix. e.g.:
version 1234 has a new package, common.foobar
version 1233 does *not* have common.foobar
jar ordering is 1233:1234
1234 is upgraded to 1234.1 which has a bug fix in common.foobar, so now
you have
1233:1234.1
and all is good
then 1233 is upgraded to 1234 and you have
1234:1234.1
and the bugfix "disappears"
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
Thanks, Dan. I would like to know if we need to have a vote on the
overall principles of shared code or if people just want to see an
examlpe implementation. I am fine either way, although personally I'd
like to make sure we agree on the principles before I spend too much
time on an implementation.
I think the requirement for a vote, be it in principle or patch comes
primarily from the resulting product behaviour changes. I think for the
changes you have proposed, that means reduced support for mixing
server and client jar versions. I think I finally understand the change
in a way that I can explain it to users and support folks that are
affected by it but know nothing about the internals of Derby, what's
shared or how, and I think it goes like this:
Behaviour Change:
Derby will continue to allow mixing different versions of
derbyclient.jar and derby.jar in the same JVM classpath but beginning
with Derby 10.2 this capability will be affected by classpath order. If
the lower revision level jar comes first in the classpath, new
functionality and bug fixes may not be available, but functionality at
the lower revision level will not be affected. Placing the higher
revision level jar first in the classpath will make the functionality
and bugfixes from the higher revision level available.
Example:
If a bug is fixed in version 10.2.1.0 (1235) and a single JVM has a
client application with version 10.2.1.0 (1234) derbyclient.jar and
an embedded application with 10.1.2.0 (1235) derby.jar in it's
classpath, it may be necessary to either upgrade the client version
to 10.1.2.0 (1235) or make sure derby.jar is first in the classpath
for the embedded application to see the fix.
Does this sound like an accurate description of the behaviour change
from the user/support perspective? Is there anything else we should
watch out for in environments where jar versions are mixed? Will
derbytools.jar be affected? Just to be clear, I am not challenging
anything here. I'm just trying to understand and make sure I explain
this to others correctly and deal with it properly from a support
perspective.
Thanks
Kathey
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
