I'm -1 to Lang. Comparators are not within its scope. It does sound like the generic comparator is really just a factory method for creating a structure of Collections comparators with a Bean comparator structure. I believe it should be a static method on the BeanUtils BeanComparator class. BeanUtils has a dependency on Collections if I'm not mistaken, so can happily get the Collections reuse, without coding the bean handling stuff again.
Hen On Fri, 3 Oct 2003, Dirk Verbeeck wrote: > The easiest way to contribute to to integrate/add your code to an > existing project. > Commons-lang looks likes a good place to start: > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/package-summary.html > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/CompareToBuilder.html > > But there is also: > http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/ComparatorUtils.html > http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/comparators/package-summary.html > > Your "|" operator is a ComparatorChain > <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/comparators/ComparatorChain.html> > > order=desc is a ReverseComparator > <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/comparators/ReverseComparator.html> > > and nulls=last can be done using NullComparator > <http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/comparators/NullComparator.html> > and your getCustomer.getLastName lookup is something for beanutils, jexl > or jxpath > > Your simple expression would be indeed a time saver for constructing a > custom comparator. > Did you already use some of the existing commons code? > If you did then I think either commons-lang or commons-collections will > be interested. > > Dirk > > > Wickus Martin wrote: > > >A while back I wrote a generic comparator for Java objects and called it > >GComp. Weve been using it internally at the company where I work, but I was > >wondering if it might not be of value to the commons project. > > > >Typically Java programmers create a custom Comparator implementation for > >every comparison scenario they encounter. GComp on the other hand can > >compare objects according to complex criteria based on a simple expression > >that explains how the objects should be compared. Great time saver and > >prevents problem of many small comparator classes bloating the code base. > > > >Usage scenario: > > > >Lets say we have a class called Customer with methods to access the first > >name and last name. Lets also say we have a class called Order that holds a > >reference to an instance of Customer. > > > >To compare orders according to the customer surname (ascending) we could > >create the following comparator: > > > >new GComp("getLastName"); > > > >To compare a collection of orders according to the customer last name > >(ascending) and then first name (descending) for those customers with the > >same last name we could create the following comparator: > > > >new > >GComp("[EMAIL PROTECTED]|[EMAIL PROTECTED] > >"); > > > >To order null values last and ignore case we could create: > > > >new > >GComp("[EMAIL PROTECTED],nulls=last|getCustomer. > >[EMAIL PROTECTED],nulls=last"); > > > > > >The above code only orders on string objects, but all objects implementing > >the comparable interface is supported as is primitive types. > > > >Currently GComp uses commons-logging to output debugging information if > >commons logging is found on the classpath. > > > >I'm happy to donate the code for further study. Let me know. > > > >Keep well, > >Wickus Martin > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
