When we last visited this issue (July 2005 thread named "Size of common
jar file"), we decided not to do anything until we had to. Well, I would
like to start writing/refactoring some small chunks of network code for
sharing by the client and server. My naive approach would be to do the
following.
o Create a new fork in the source code: java/common. This would be
parallel to java/client and java/server.
o This fork of the tree would hold sources in these packages:
org.apache.derby.common...
o The build would compile this fork into classes/org/apache/derby/common/...
o The jar-building targets would be smart enough to include these
classes in derby.jar, derbyclient.jar, and derbytools.jar.
As I recall, there was an edge case: including a derby.jar from one
release and a derbyclient.jar from another release in the same VM. I
think that a customer should expect problems if they mix and match jar
files from different releases put out by a vendor. It's an old
deficiency in the CLASSPATH model. With judicious use of ClassLoaders, I
think customers can hack around this edge case.
I welcome your feedback.
Cheers,
-Rick
