Yes, that's correct, that's the intent of the forward-compatibility
guidelines and mechanisms.
I could add this text:
"Older versions of Derby jars will get their expected behavior in a
mixed version environment regardless of jar ordering. Newer versions of
Derby jars will get their expected behavior as long as the newer jar
files are loaded first."
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
This contribution provides mechanisms and guidelines, such as
guidelines and tools for supporting forward and backward
compatibility, to help ensure that Derby jars with different versions
can be loaded in a Java VM without having to use specialized
classloaders. If an incompatibility exists between versions, it will
be clearly documented. Any undocumented incompatibilities will be
treated as a bug.
However, not all issues can be resolved. For example it is possible
for "shadowing" to take place if there are different versions of
network client and embedded client in the same VM, and each provides a
different implementation of the same common method.
I think that it would be good to communicate that in such cases
regardless of the order the jars are loaded, functionality will not be
affected at the lower revision level for either the embedded or client
jar. The higher revision behaviour can be used if the higher revision
jar is loaded first.
Is that true? And if so can we include it in the vote?
For instance if I have a 10.2 derbyclient.jar and a 10.3 derby.jar in
the same JVM, everything should work ok at the 10.2 level regardless
of class loading order, but If I put derby.jar first, the embedded
application should be be able to function at the 10.3 level and the
client at the 10.2 level.
Thanks
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
