commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: Util 1.0? - Let's house the homeless
Date Fri, 22 Feb 2002 02:37:15 GMT
Charles Burdick <charles_burdick@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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message