You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Chuck Burdick <ch...@yahoo.com> on 2002/02/21 17:26:03 UTC
Util 1.0? - Let's house the homeless
After browsing the CVS tree, it seems that many of the 'util' objects
have legitimate homes elsewhere.
Below, I've listed a suggested "relocation plan" for the items in Util,
based on class names and a cursory glance through the source.
It seems clear that we need a commons/lang package for Object, Class,
and Exception-related tools. Given that, then only 3 classes to me seem
to be truly homeless, 2 of which are related to Soundex. (How "common"
is it really?)
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.
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.
I'm not a committer, but I am a frequent user and occasional
contributor. IMO, Utils as a package diminishes the *usability* of
Commons.
Thanks,
Chuck
[IO]
src/java/org/apache/commons/util/Base64.java
src/java/org/apache/commons/util/BitField.java
src/java/org/apache/commons/util/BufferCache.java
src/java/org/apache/commons/util/FileUtils.java
src/java/org/apache/commons/util/HexDump.java
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
src/java/org/apache/commons/util/LockableFileWriter.java
src/java/org/apache/commons/util/StreamUtils.java
src/java/org/apache/commons/util/GenerateUniqueId.java
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
[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
[COLLECTIONS]
src/java/org/apache/commons/util/CollectionsUtils.java
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
src/java/org/apache/commons/util/EnumerationIterator.java
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
src/java/org/apache/commons/util/MapUtils.java
src/java/org/apache/commons/util/SequencedHashtable.java
src/java/org/apache/commons/util/StringStack.java
[HOMELESS]
src/java/org/apache/commons/util/Soundex.java - [IO? SOUNDEX?]
src/java/org/apache/commons/util/compare/SoundexComparator.java - [COLLECTIONS? IO? SOUNDEX?]
src/java/org/apache/commons/util/XmlUtils.java - [XERCES? JDOM?]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Util 1.0? - Let's house the homeless
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Charles Burdick <ch...@yahoo.com> writes:
> --- bayard@generationjava.com wrote:
>> > src/java/org/apache/commons/util/BufferCache.java
>>
>> Again. un-IO?
>
> Yeah, I was mislead by its class name. How is this used? Perhaps it
> needs to be renamed and put in Collections.
I would like to remove this class in the re-org. It's just a LRU-like
storage class.
>> > 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.
Craig suggested the possibility of a servlet-util package. HTTP
client was brought up as another possiblity.
>> > 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?
>
> Are you saying that these are not IO? GenerateUniqueId could go in
> servlet (if that's its main usage). The others seem undeniably IO.
GenerateUniqueId should remain in util -- it was indeed originally
part of JServ, but its useful for more than just servlets.
>> > 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 :)
BufferCacheTest will go away, and I believe that
SequencedHashtableTest is already in Collections as
SequencedHashMapTest (so it can go away too).
>> > [COLLECTIONS]
>> The only issue with the compare/ library is dependency. It depends
>> on Lang so Collections might not want it until Lang is there.
>
> Hmm... Good point. That's difficult to resolve. Perhaps a collections
> extension package of comparators?
>
> It seems like the basic data stores in collections should have no
> outside dependencies. However, extensions with dependencies might be
> good.
Why not just leave the Comparators in util? That's definitely
JDK-like.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Util 1.0? - Let's house the homeless
Posted by ba...@generationjava.com.
> > > 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?
>
> Are you saying that these are not IO? GenerateUniqueId could go in
> servlet (if that's its main usage). The others seem undeniably IO.
My fault. 'this' just meant the last one :) I think the difference is that
I'm thinking in terms of where something should go rather than where it's
main usage is. In that way, it hopefully will be used by more things. The
bad side of this is that it will create more cross-dependencies.
> > > [COLLECTIONS]
> > The only issue with the compare/ library is dependency. It depends on
> > Lang
> > so Collections might not want it until Lang is there.
>
> Hmm... Good point. That's difficult to resolve. Perhaps a collections
> extension package of comparators?
>
> It seems like the basic data stores in collections should have no
> outside dependencies. However, extensions with dependencies might be
> good.
>
I'll take a look at the xml classes you mentioned. My view for the xml
code is that it should stay in the sandbox until its grown. I guess
there's no reason that something that grows in the sandbox can't then
leave it to go into jdom or dom4j.
Bay
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Util 1.0? - Let's house the homeless
Posted by Charles Burdick <ch...@yahoo.com>.
Comments below.
--- bayard@generationjava.com wrote:
> > src/java/org/apache/commons/util/BitField.java
>
> I missed this one :) It seems un-IO.
Yeah, at second glance, maybe it could go in commons/lang? It seems
more like Byte, Integer, etc. than IO stuff. It's unfortunate that Sun
packaged BitSet in java.util.*. BitSet and BitField are kinda
siblings.
>
> > src/java/org/apache/commons/util/BufferCache.java
>
> Again. un-IO?
Yeah, I was mislead by its class name. How is this used? Perhaps it
needs to be renamed and put in Collections.
> > 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.
Sounds good.
> > 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?
Are you saying that these are not IO? GenerateUniqueId could go in
servlet (if that's its main usage). The others seem undeniably IO.
> > 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 :)
Oops, my mistake.
> > [COLLECTIONS]
> The only issue with the compare/ library is dependency. It depends on
> Lang
> so Collections might not want it until Lang is there.
Hmm... Good point. That's difficult to resolve. Perhaps a collections
extension package of comparators?
It seems like the basic data stores in collections should have no
outside dependencies. However, extensions with dependencies might be
good.
> > 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.
Yeah, Xerces would be overkill. XMLUtils is much more centered around
String snippets within a larger XML-ish context. It may be useful to
have a full package of such tools. However, take a look at
http://www.jdom.org/docs/apidocs/
- org.jdom.Element
- org.jdom.output.XMLOutputter
- org.jdom.intput.*
You may be surprised at how small and useful the package is. You can
do a lot without creating an entire DOM, and it handles all the
escaping issues nicely. Perhaps String-centered pieces could be
incorporated into org.jdom.input.* for easy pseudo-parsing.
JDom is currently Apache-like licensed. It has been accepted as
JSR-102, so who knows what will happen once Sun gets a hold of it!
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Util 1.0? - Let's house the homeless
Posted by ba...@generationjava.com.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>