commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Size and scope issues
Date Mon, 03 May 2004 15:43:14 GMT
Thanks for responding, its useful to try to understand WHY there are isues
with collections and other commons packages.

I'll correct one point of fact below - the commons-collections-SNAPSHOT is
earlier in time than v3.0, and represents a state before the primitive
collections got kicked out (precisely because I worried about size and scope
at that point). The latest jar size is 548k. This affects your next comment.
Also, FYI 2.1 to 3.0 represents a very large jump in time, over 18 months
IIRC.

I will try and get a breakdown of sizes within the jar at some point to try
and understand this further. I evaluated the code today, and found that
picking and choosing classes for a smaller jar would prove difficult - there
is quite high reuse within the package, and lots of backwards compatability
to consider.

Finally, I would say that if you have such a small target size, then I
suspect that you will always take the pick and choose (repackage) option
with collections. So my question would go back to your as, if there was a
collection/list/set/map only jar (no bag/bidimap/buffer/comparator/functor),
would you use it? Bear in mind that in order to produce more jars, the
overall size will actually have to go up.

Stephen


----- Original Message -----
From: "Dain Sundstrom" <dain@coredevelopers.net>
> 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
>
> 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
> rate.
>
> 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
>
> /*************************
>   * 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" <robertburrelldonkin@blueyonder.co.uk>
> >>> 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: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message