commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [collections] Size and scope issues
Date Thu, 22 Apr 2004 04:40:42 GMT
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 the
> >>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 be.

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

> ..but #2 is a very strong perception, smelling like "real reality", to me.

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

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 jar.
> >  
> >
> 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. For
> >that it requires a good package layout, complete and logical set of classes
> >(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

> 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