db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Sharing code
Date Mon, 05 Sep 2005 01:39:42 GMT
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


Mime
View raw message