commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Burdick <charles_burd...@yahoo.com>
Subject Re: Util 1.0? - Let's house the homeless
Date Thu, 21 Feb 2002 17:51:21 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message