Sorting objects based on potentially null property values

[Peter van Zetten]

I'm trying to sort of a list of objects (objects) using a BeanComparator/NullComparator combination, based on a property (propToSort) of the object.

This code can be hit in a variety of situations, and sometimes the propToSort value may be null. If this is the case, I'd like the comparator to put it at the bottom of the list, as the NullComparator does for the Objects.

At the moment it throws a null exception if that property value is null - not what I want.

For example, the objects list contains items with propToSort values of:
- gamma
- null
- beta
- null
- alpha

When sorted, I would like it to be:
- alpha
- beta
- gamma
- null
- null

If the list contains only objects with propToSort values of null, the list would be unaltered at the end of the sort.

This is what I have at the moment.

List sortedObjects = this.objects;
    	
BeanComparator beanComparator = new BeanComparator("propToSort");
org.apache.commons.collections.comparators.NullComparator nullComparator = new NullComparator(beanComparator, false);

if ((sortedObjects != null) && (nullComparator != null))
{
	Collections.sort(sortedObjects, nullComparator);
}
        
this.objects = sortedObjects;

I'm really just a Java beginner, so if there's a better way to do this, please let me know.

[Campbell Ritchie]

If the List contains fields all with null values, then there is no detectable difference between them, so there will be no sorting.
The problem would have to be sorted out in your compare method. If one of the values is null and the other isn't, return 1 or -1 automatically. If both the values are null return 0. If neither value is null you will have to do some work

[Peter van Zetten]

I could write a manual sorting method and do it that way, but I was hoping there would be something built-in.

Is there no Comparator-type object in a standard library which can handle null values in the sorting property?

[Campbell Ritchie]

The whole idea of Comparator being an interface is that you use the same title (Comparator<T>) but different functionality each time. So you have to write the code for inside an interface yourself.

[Peter van Zetten]

Thanks for your help, I did manage to get it in the end by adding a compareTo method to the object itself; not where I had the code I listed. I'm afraid I didn't really understand what you were getting at originally, but after reading up some more I think I've got a better grasp of Comparators now.

I had a further hiccup with the equals method, but I managed to get that sorted on my own

Thanks again.

[Campbell Ritchie]

Did you really get equals sorted? The equals method looks very easy, but it isn't.

[Peter van Zetten]

I got it sorted in the sense that I stopped trying to do it myself...

I did write a bit of the method, but I hit a snag when I was trying to remove one of these objects from a List, and it kept returning [0] as the indexOf, because I was only checking a few properties which turned out to be common to the objects in the List.

Then I started to write it up to check every property of the object (and properties of those properties, etc.), but I realised that I only really needed the built-in object.equals method, so I got rid of my override.

So yeah, sorted :P

[Campbell Ritchie]

Object#equals works on the strictest possible basis, something like this

public boolean equals(Object o)
{
    return o == this;
}

So you would have to override the equals method so you can pass two identical objects and have them recognised as "the same" or "equal". This appear easy, but it isn't, so find a copy of Joshua Bloch's book or Angelika Langer's article before trying it.