On 21 Feb 2002, Chuck Burdick wrote:
> I find it disturbing that some Utils look like blantant duplication of > effort! SequencedHashtable, MapUtils, CollectionUtils, etc. are already > in Collections. Also XMLUtils seems redundant/misplaced given the tools > already available - Xerces, JDom, etc. Some are legacy, some are my fault I think. I argue against XmlUtils being redundant as there's a world of difference between a simple set of classes to manipulate xml without parsing and the parsin of xerces/jdom/etc. I see no need to parse an xml file fully to be able to deal with it. I may just be unaware of classes in the depths of those parsers though. > > I agree that sandbox/util could serve as an Ellis Island of sorts for > entry into other Commons packages. But I strongly disagree with Util as > a package on its own. agreed. > [IO] > src/java/org/apache/commons/util/Base64.java This is in a lot of places. Email, Codec, Utils, in the sandbox. Who truly owns it? Codec seems to be building around it. > src/java/org/apache/commons/util/BitField.java I missed this one :) It seems un-IO. > src/java/org/apache/commons/util/BufferCache.java Again. un-IO? > src/java/org/apache/commons/util/FileUtils.java > src/java/org/apache/commons/util/HexDump.java Well. It throws IOException and takes OutputStream, so +1 from me. > src/java/org/apache/commons/util/http/BrowserDetector.java > src/java/org/apache/commons/util/http/HttpUtils.java > src/java/org/apache/commons/util/http/RequestUtils.java There's been suggestion for a 'servlet' package. These might go in there, though IO seems an option too. > src/java/org/apache/commons/util/LockableFileWriter.java > src/java/org/apache/commons/util/StreamUtils.java > src/java/org/apache/commons/util/GenerateUniqueId.java This has no IO-ness to it at all? > src/test/org/apache/commons/util/BitFieldTest.java > src/test/org/apache/commons/util/BufferCacheTest.java > src/test/org/apache/commons/util/HexDumpTest.java > src/test/org/apache/commons/util/SequencedHashtableTest.java I assume not to the last one. And BufferCache. And bitfield :) > > [LANG] > src/java/org/apache/commons/util/ClassUtils.java > src/java/org/apache/commons/util/exception/Nestable.java > src/java/org/apache/commons/util/exception/NestableDelegate.java > src/java/org/apache/commons/util/exception/NestableException.java > src/java/org/apache/commons/util/exception/NestableRuntimeException.java > src/java/org/apache/commons/util/NumberUtils.java > src/java/org/apache/commons/util/ObjectUtils.java > src/java/org/apache/commons/util/StringUtils.java > src/test/org/apache/commons/util/StringUtilsTest.java Sounds good. StringUtils actually has some inner classes. Done that way because it was expected that it would be moving elsewhere at some soon point (well within a year). Those are: CharRange, CharSet and Metaphone. The first two are Lang-y. The second goes where-ever Soundex goes as it's another Soundex algorithm. > > [COLLECTIONS] > src/java/org/apache/commons/util/CollectionsUtils.java [Maybe DIE?] > src/java/org/apache/commons/util/compare/ComparableComparator.java > src/java/org/apache/commons/util/compare/NumericStringComparator.java > src/java/org/apache/commons/util/compare/PackageNameComparator.java > src/java/org/apache/commons/util/compare/ReverseComparator.java > src/java/org/apache/commons/util/compare/UrlComparator.java The only issue with the compare/ library is dependency. It depends on Lang so Collections might not want it until Lang is there. > src/java/org/apache/commons/util/EnumerationIterator.java [DIE?] > src/java/org/apache/commons/util/lru/ILRUElement.java > src/java/org/apache/commons/util/lru/LRUElement.java > src/java/org/apache/commons/util/lru/LRUElementDescriptor.java > src/java/org/apache/commons/util/lru/LRUElementImp.java > src/java/org/apache/commons/util/lru/LRUStore.java > src/java/org/apache/commons/util/lru/LRUStoreImp.java Suggest as a subpackage of Collections yes. > src/java/org/apache/commons/util/MapUtils.java [DIE?] > src/java/org/apache/commons/util/SequencedHashtable.java [DIE?] > src/java/org/apache/commons/util/StringStack.java > > [HOMELESS] > src/java/org/apache/commons/util/Soundex.java - [IO? SOUNDEX?] I really don't know :) > src/java/org/apache/commons/util/compare/SoundexComparator.java - [COLLECTIONS? IO? >SOUNDEX?] Ditto. > src/java/org/apache/commons/util/XmlUtils.java - [XERCES? JDOM?] Getting it lost in those projects seems wrong. I think the goal of an xml subproject would be to provide somethign more than indexOf, but less than a parser. I'm happy to do a proposal for this subproject too, or for it to go into Lang or IO or stay in the sandbox. Bay -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
