Thanks, Jeremy. Interesting point. If we can assume/require full
backward-compatibility as I am proposing, we can have the following
classpath:
derby-10.1.jar;derbyclient-10.2.jar:derbycommon-10.2.jar
and the 10.1 code should work just fine.
Is it possible that you may still end up with a classpath where the
derbycommon-10.1.jar shows up ahead of the 10.2 jar file and the user is
unable to remove it?
Thanks,
David
Jeremy Boynes wrote:
David W. Van Couvering wrote:
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.
Others have pointed out the problems here with classpath ordering.
The root of this is that the same classes are being included in
multiple jars leading to potential duplication. This can be avoided by
placing them in a separate jar so that each is only present once e.g.
derby-10.2.jar:derbyclient-10.2.jar:derbycommon-10.2.jar
The downside of this is that multiple jars need to be included to form
a complete solution. Concern has been expressed in the past about
exceeding the length of the CLASSPATH environment variable. However,
most frameworks today, including J2EE, do not use that mechanism to
include libraries relying instead on features like the manifest
classpath, extensions, WEB-INF/lib, uber-jar or others provided by a
container environment.
IMO the benefits of a more modular structure and a clear lack of
duplication exceed the benefits of a bundled distribution and I would
prefer to see the common code distributed separately.
--
Jeremy
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
