commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <bay...@generationjava.com>
Subject Re: Util 1.0? - Let's house the homeless
Date Thu, 21 Feb 2002 16:46:23 GMT

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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message