Michael A. Smith wrote: > To me, at least, that implies we'd have an > "io" component, a "lang" component, etc, > where the appropriate utilities would > reside. Things like util.CollectionsUtils > would move to commons.collections.Collections > or collections.Utils or something.
I couldn't agree more. It would depend on the proposal of course, but I'm pretty sure I'd -1 any proposal for a component with a scope as generic as Util's seems to be, especially when it already contains stuff the overlaps with the scope of existing commons components. > After looking at some of the other classes in the util > component, I believe this is a better way to go, > especially with collections related classes. There's > already some duplication between utils and > collections (SequencedHashtable vs. SequencedHashMap, > BufferCache vs. LRUMap, and EnumerationIterator vs. > EnumerationIterator). If "collection" related > utility classes went into collections rather > than util, this may not occur. Some "guidelines" from the charter that seem to speak on this point: "1. The primary unit of [...] release is the package." "3. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts." I'd much rather see Util broken up into multiple, independent component proposals (perhaps along the package lines you all have been discussing), each with a well defined purpose. A monolithic "component" like Util seems like a step back from the reason commons was created. - Rod
