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 file. > > ..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 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 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 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. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
