db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Sat, 10 Sep 2005 01:40:48 GMT
David W. Van Couvering wrote:
> Well, this is an interesting wrench you have thrown in here, Jeremy.  

Wrenches are a specialty of the house :-)


> The question is, what are the benefits of the approach, and do they 
> merit the rigor that we would have to follow to make sure things don't 
> break?  I have to think about this myself.  What do others think?

The big benefit I see is not technical but social. AIUI Jakarta Commons 
evolved out of the recognition that large projects (specifically Tomcat) 
provided many libraries that would be valuable for other projects to 
use. By separating them out it made is possible for people to contribute 
in a meaningful way without needing to grok the whole of a large project 
in its entirity.

Commons itself went through a process of evolution, both in terms of 
stability and in terms of modularity (decoupling the libraries from each 
  other). It now provides a useful resource for open source and 
commercial projects alike.

In many cases the rigour is not there to the same extent as in typical 
closed source implementations. Instead, the use of classloader 
hierarchies allows modules to be loaded into separate domains with 
multiple versions present in memory concurrently.

This is analogous to the J2EE model where the application server needs 
to be able to load different class versions for the different 
applications it is hosting. However, it is also used by frameworks like 
Spring, Eclipse, Plexus (Maven), Ant etc. in more specialized niches 
than a general purpose application server.

> P.S. Jeremy I don't understand why separate classloaders are needed to 
> work with different versions in the same VM, if we meet compatibility 
> rules.

I was thinking of the case where they do not meet compatibility 
requirements for co-location, for example a 11.X client talking to a 
10.X engine. The in-VM, cross-classloader mode would allow these to work 
together without having to use a network connection.

For most co-location situations though I would anticipate that the 
compatibility rules combined with the clear separation of classes into 
distinct modules would allow the user to assemble an unordered list of 
jars that could be loaded by a single classloader.


View raw message