On Thu, 22 Apr 2004, 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.
I agree. > 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! Perhaps some of the classes in [collections] could be presented as a JSR for inclusion in the JDK at some later date. That might cut the size of the jar some. :) michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
