commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] Size and scope issues
Date Thu, 22 Apr 2004 19:17:51 GMT
Its always good to see the opposing points of view ;-) Thanks for all

Following this discussion I did a search around the web to try and find
references to collections causing a problem by its size. I didn't really
find any, but that doesn't prove anything.

The appserver point is part of what jakarta is about, and dropping in a
library should not result in concerns over size. On the other hand, projects
like beanutils and digester which used one collection each are quite correct
to terminate the dependency and cut and paste.

One point I should make is that commons frequently gets requests to release
everything as one jar. Finding the right component size is always tricky. I
would argue collections is about right. The biggest query is really over the
functors, but thats a long story - see the mail archives for the pain that
they were.

I would also argue against having a collections-all and collection-part
release strategy. Its all too easy to mess up and to have an old
collections-all blocking a newer collections-part.

Finally, half the problem with size in collections comes from the Sun
interfaces. Map especially requires an awful lot of classes to implement,
and that takes up space ;-)

I will go and have a look to see if anything can be done to trim space. Who
knows, there may be something simple!


----- Original Message -----
From: "Simon Kitching" <>
> On Thu, 2004-04-22 at 08:48, paulo gaspar wrote:
> > Stephen Colebourne wrote:
> > >>IMO, the collections package:
> > >>1) should have really commonly used collections that are missing on
> > >>java.util package and also
> > >>    some usefull collections building blocks for especial cases;
> > >>2) should NOT be a contest to implement all possible classes that have
> > >>something to do (even
> > >>    remotedly) with collections, doesn't mater how special they might
> I think that collections is fine as it is.
> Jakarta's whole goal is to provide "server" components for java. If
> these happen to also be useful for applets, then that is great. However
> I believe that those people who want to use jakarta components in
> environments that are constrained by network bandwidth or RAM or disk
> space are responsible for themselves repackaging the bits they want.
> Remember, if anyone wants to write an applet and use some of the great
> collection classes in commons-collections, there is nothing to prevent
> them from selecting the classes they want and creating a custom jar
> file.
> >
> > ..but #2 is a very strong perception, smelling like "real reality", to
> And it smells differently to me. I like having a single project that
> collects a number of collections together. In fact, I would probably
> have preferred to have the primitive collections in the same project and
> jar.
> Having "unused" classes present in a jar takes up a little disk space.
> But it doesn't have any runtime cost for server environments. For
> applets or "webstart" applications, yes. But that's not jakarta's focus.
> And as noted above, those application developers are welcome to select
> and repackage the classes they desire.
> > >
> > >
> > I am sure all the weirdest collections were used at least once. But
> > should that be enough?
> It's a grey area. But if the regular developers on a project are willing
> to create and maintain the code (including writing unit tests for it),
> then I reckon I'd trust their judgement.
> > >
> > But ONLY those not-in-JDK need unmodifiable decorators.
> >
> > Completness is often a weak reason for too much featuritis/crap.
> This sounds like a good guideline to me. I agree that in general stuff
> should be added only when there is a demand for it.
> However quite a lot of people are too shy to ask for stuff. And of
> course when they want it, they want it *then*, not to wait for the next
> release. So quite a lot of the time even when there *is* demand for a
> feature, no email or bugzilla request is made [I'm guilty of this
> myself]. So the project developers should use their judgement on whether
> features are actually likely to be used.
> > I am not sure that being able to extract the decorated object is a
> > feature. I would qualify it as a Bug
> > in most of the contexts where I use such thing.
> >   - E.g.: in a IoC design, if I give to some component a UnmodifiableMap
> > it is usually because I
> >     REALLY, REALLY want to avoid any possibility of that component's
> > code being able to change
> >     the decorated Map.
> Well, it's always possible; anything the collections API can do, the
> user could have done anyway.
> > This means that I am not against having even the incredible Flat3Map
> > packaged in some way. My
> > problem is that I am overloaded with so much stuff if I want to use the
> > most "obvious" and
> > "common" collections.
> >
> > My dream is that Collections would be split in smaller subprojects,
> > corresponding to smaller
> > packages (and docs/javadocs) to deal with. A big all-in-one package,
> > compatible with the current
> > monster-jar should still exist.
> Yes, but that introduces complexity in another manner. Is having one
> library with 100 classes better or worse than 10 libraries with 10
> classes each?
> To learn what facilities are available in those 10 libraries, you would
> have to go to 10 different websites and browse 10 different lots of
> javadoc. Just see the commons FAQ for a user request to provide the
> whole of commons as a single set of javadoc.
> And my server app which uses a number of different collections would
> need 10 jars in the classpath not just one. And I would have to track
> dependencies between my app and 10 different projects, not just one.
> >
> > I would just like to have an easy "standard" alternative to the monster
> >
> > >
> > >
> > IMO, dividing would still make everybody happy.
> > =:o)
> It wouldn't please me. See, the collections maintainers just can't win
> :-)
> >
> > >Having said all that, it must be born in mind that [collections], like
> > >[lang], operates in two ways. The first is as a jar file dependency.
> > >that it requires a good package layout, complete and logical set of
> > >(no holes) and clear docs.
> > >
> > >
> > This (no holes) thing is also something that must be taken with a grain
> > of salt...
> Yes, I would agree. The goal of "completeness" is sometimes
> counter-productive.
> > Seriously, not only do I see the primites out, but I also have the idea
> > that everything is better
> > placed and fits better together. Last time I was just going to quit
> > using Collections, now I am taking
> > the time to bother you into providing alternative packaging.
> > =:oD
> I appreciate your comments and point of view. I'm sure Stephen does too.
> Unfortuately, the kind of stuff I want to do with collections causes me
> to lean in the other direction - to request that collections not be
> fragmented into any more projects than it already is.

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

View raw message