Comparator vs Apache BeanComparator

Question

Consider a simple class:

class Employee {

String name;
int sal;

....//getters and setters
}

I can create a Comparator to sort on field name for example.

class EmpSortByName implements Comparator<Employee>{

 @Override
 public int compare(Employee e1, Employee e2){
  return e1.getName().compareTo(e2.getName());
 }
}

However, looking at apache commons BeanComparator, sorting can be achieved in following way:

BeanComparator bc = new BeanComparator("name");
Collections.sort(employeeList, bc);

Thus, by using BeanComparator, I can achieve sorting with minimal code. What are the trade offs between using Comparators and BeanComparators: in terms of performance, usage scenarios (multiple fields sort, other factors)?

I also understand that to use BeanComparator, the beanutils jar has to be imported.

Solution 1

The BeanComparator uses reflection to access the name property and compare the two objects. Although reflection performance has improved, it's still not as fast as accessing a field directly. Whether this is important or not depends on how many times it's called in your application, and in which context.

Another problem is that, if you refactor the method and rename it to getLastName(), the code using BeanComparator will not be refactored, and the problem will go unnoticed until runtime (or unit testing time).

Frankly, implementing a comparator is so easy that I don't think using reflection is a good idea. The benefit of avoiding 4 lines of trivial code isn't sufficient to compensate for the performance and maintainability problems it causes.

Solution 2

Also with beancomparator you can compare more that one attribute in easy way with compareTuple org.ujac.util.BeanComparator beanComparator = new org.ujac.util.BeanComparator(compareTuple); Collections.sort(List,beanComparator);

Comments

[aces.]

@JB You are correct, due to reflection there will be performance hit. In what circumstances should BeanComparator used? Is 'minimal' code the only reason? Can you think of any other reason?

[JB Nizet]

I've never had the need to use it myself, but I can imagine using it in unit tests, or when a UI allows dynamically choosing on which properties objects must be sorted, or in a JSP tag like displaytag, which has to compare beans without even knowing their type without the need for the developer to provide a comparator

[Rohit]

In the context of above problem I agree with this solution but what if you have to sort on a given field of the class. If class has too many fields then we cannot write a comparator for each field, hence BeanComparator should be used.

[djmj]

Without reflections and generic filtering our JSF, Hibernate enterprise application would have a much larger code base to maintain with endless specific DAO's, Converters, Comparator's, filters. The rename argument is valid, but we hope java lambda's will one day be supported by all third-party libraries making it obsolete. In C# stack its easy to pass dynamic predicates without String bean paths. For instance primefaces lazy datatable gives you a map of filters with bean property path notation. You must use reflection if you don't want boilerplate code.