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
