commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [collections] Size and scope issues
Date Mon, 03 May 2004 15:12:32 GMT
I can say that it is not politics for the Geronimo project.  Our goal 
is to keep our stand alone kernel small (under 4mb) and a full Geronimo 
server under 16mb (I'm shooting for under 8).  Small size is important 
as it directly effects the places where people will be using the 
server.  There is a demand for J2EE servers in small hardware.  Anyway, 
just taking a quick look at ibiblio this is the history of 

commons-collections-1.0.jar            84k
commons-collections-2.0.jar            88k
commons-collections-2.1.jar           161k
commons-collections-3.0.jar           506k
commons-collections-SNAPSHOT.jar      842k

I find it hard to believe that there are almost 1mb of truly common 
collections.  Either way, the writing is on the wall, the package is 
growing and growing quickly.  Not only that, since this library is 
widely used in commons, all of those projects are growing at a rapid 

Building small tight code is not easy, especially as Craig put it the 
other day "perceptions of 'really common' versus 'rarely used' seem to 
be awfully personal".  The alternative is you end up with huge 
highly-coupled libraries and no one wants to use them anymore.

Instead of just bitching, I'll suggest a possible solution.  Pick 
someone in your project who understands the issues, has shown an 
interest in these problems, and give them the authority to make 
decisions.  I know it is not very "Apache", but I believe it will work.


  * Dain Sundstrom
  * Partner
  * Core Developers Network

On May 3, 2004, at 2:11 AM, robert burrell donkin wrote:

> i definitely agree that one jar is the best solution for many users. 
> for those users for whom jar size is a big issue, then i'd say for 
> that for many use cases rolling a custom version (possibly repackaged) 
> is the best approach. (i have heard that this is how BEA re-uses the 
> commons logging stuff.)
> but we've been hearing that for some users - many of them influential 
> open source developers - this approach is unsatisfactory. one of the 
> main aims for jakarta commons was to facilitate re-use of library code 
> between open source projects. there are a few of ASF projects who are 
> refusing to use any jakarta commons components on principle now for 
> this reason. (they want small, tight libraries.) i suspect that this 
> is partly political but there is a kernel of truth in the criticisms. 
> it's best to think about this kind of issue early before a momentum 
> develops.
> certainly, i'm keen to see digester 2 (if and when it comes along) 
> factored into a small core with minimal dependencies together with 
> optional extensions. the binary distribution would contain both a 
> single complete jar and a set of multiple jars. i hope that this 
> should be able to satisfy most users and since this is just a build 
> issue, i suspect that the maintenance would be minimal.
> - robert
> On 3 May 2004, at 00:41, Stephen Colebourne wrote:
>> So what problem are we solving? Adding extra jar files alongside the
>> complete built one creates classpath problems for users, an old 
>> version of
>> the 'all' jar overriding a later version of the 'part' jar or vice 
>> versa.
>> General chaos and confusion.
>> People so have the ability to build their own jar files with just the
>> classes they need.
>> Oh, and I'd also suggest that more jar files does involve more work
>> (maintaining and releasing), and there's a distinct lack of active
>> committers on collections as it is ;-)
>> Stephen
>>> On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote:
>>>> A neat ideal, but perceptions of "really common" versus "rarely 
>>>> used"
>>>> seem to be awfully personal.  Kinda reminds me of earlier 
>>>> commons-dev
>>>> discussions trying to create a "commons core" JAR that included all 
>>>> of
>>>> the "really common" commons JARs, and none of the others.  Needless 
>>>> to
>>>> say, there was no consensus on what the contents should be :-).
>> From: "robert burrell donkin" <>
>>> i wonder whether it might be possible to separate out a core jar
>>> containing just the basic interfaces and then split the 
>>> implementations
>>> into several themed jars. i still think that this should be in 
>>> addition
>>> to releasing a single jar containing everything, though.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message