David W. Van Couvering wrote:
Well, this is an interesting wrench you have thrown in here, Jeremy.
Wrenches are a specialty of the house :-) <snip/>
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.
-- Jeremy
