On Thu, Apr 22, 2004 at 08:17:51PM +0100, Stephen Colebourne wrote: > Its always good to see the opposing points of view ;-) Thanks for all > feedback. > > 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!
Stephen, Maybe the proxy stuff I suggested for [events] could work for most of the decorators we have in [collections]. And as I said for [events], in many cases, one decorator fits many collections, so this could help to reduce the size of [collections]. Anyway, there might be performance issues with proxies... but I don't know much on this subject actually. Herve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
