commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject RE: [COLLECTIONS] Comparator observations
Date Fri, 01 Mar 2002 15:54:53 GMT
> I know you have an opinion.  I was hoping someone else 
> would say something as well.  :)

Ok, I'll bite.  I think I'm with Morgan, neither UrlComparator nor
NumericStringComparator seem generic enough to warrant being part of a core
commons-collections package.

UrlComparator currently sorts URLs by host, then path, then protocol, then
port, which is a reasonable (though it ignores query strings) but rather
application specific ordering.  It's no less reasonable to say I'd like to
sort by protocol before path, or protocol before host, or to sort hosts so
that I get ",," rather than ",," (by domain before machine
name), or by TLD first, or that I'd like the query string to be significant,

Also, the use of the URL.getPath method introduces a dependency on JDK 1.3,
perhaps the first 1.2 incompatibility in commons-collections.

I think NumericStringComparator has similar problems, although perhaps not
to the same degree. There are lots of variations that an application may
want to support:


(basing the NumericStringComparator on a java.text.NumberFormat instance may
be helpful here), and for that matter, if I'm mixing numbers and Strings,
why not dates, monetary values, etc.

Fundamentally, it's not that I think that UrlComparator and especially
NumericStringComparator aren't useful or reusable outside of the
applications for which they were created, it's more that I think they have a
different kind of scope than the rest of commons-collections, and hence
their inclusion would begin to confuse or pollute that scope.  I wonder if
it would be useful have some sort of collections add-ons JAR (not unlike
Ant's optional.jar) that could include things like UrlComparator and
NumericStringCompatator and other domain specific (but not
application-specific) classes.

 - Rod

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message