Purpose, use of and queries regarding the Objects.compare utility method - object

Question

I have a question about using the new Objects.compare(o1, o2, Comparator) method - from my own testing of it, if both o1 and o2 are null then it returns 0, however, if one of them is null then it still throws a null pointer exception. I have found a lot of material on Objects.equals and some of the other Objects utility methods but not much at all on Objects.compare and when we are expected to use it / replace old code with it.
So here I could do this:
String s1 = "hi";
String s2 = "hi";
int x = Objects.compare(s1, s2, Comparator.naturalOrder());
System.out.println("x = " + x);
That works fine, returns 0, now this:
String s1 = null;
String s2 = null;
Also works fine and returns 0. However, this:
String s1 = "hi";
Strng s2 = null;
Throws a NullPointerException. I'm guessing the benefit of Objects.compare(o1,o2,Comparator) vs o1.compareTo(o2) is that it at least handles circumstances where both objects are null and when one of them is null it allows you to design a Comparator to handle it. I'm supposing, e.g.
int x = Objects.compare(s1, s2, Comparator.nullsFirst(Comparator.naturalOrder()));
Whereas with x.compareTo(y) there's no way to handle null unless you do so beforehand? So do the Java library developers now intend us to replace all calls to compareTo with Objects.compare, when we're concerned about nulls? e.g. would we do this in our Comparable implementations?
Side query 1: With regards to using nullsFirst if you use it then pass in a Comparator, which is chained using comparing, thenComparing, etc, does it apply to all of the inner comparators? e.g.
Comparator.nullsFirst(Comparator.comparing(Song::getTitle)
.thenComparing(Song::getArtist)
.thenComparing(Song::getDuration)
)
Would that apply nullsFirst to everything inside or do you need to use nullsFirst individually on each of them? I think from testing that it only applies to the actual Song objects being null, not for the fields of title or artist being null, i.e. if they are null then a NullPointerException is still thrown. Anyway around that?
Side query 2: final question is that because I like the Comparator.comparing syntax, I'm proposing to start to write my compareTo implementions using it - I was struggling to think how to replace this traditional approach, e.g.
public int compareTo(Song other) {
int result = this.title.compareTo(other.title);
if (result == 0) {
result = this.artist.compareTo(other.artist);
if (result == 0) {
result = Integer.compare(this.duration, other.duration);
}
}
return result;
}
then I thought I could use Objects.compare(...) as follows:
public int compareTo(Song other) {
return Objects.compare(this, other, Comparator.nullsFirst(
Comparator.comparing(Song::getTitle)
.thenComparing(Song::getArtist)
.thenComparingInt(Song::getDuration)
));
}
I thought this version was more elegant - I am assuming it is working as I think it is, e.g. by passing this and other as the first 2 arguments then the comparator, it has the same effect as the traditional compareTo approach with if statements? Whilst I can see that the benefit of Objects.compare catching two nulls would never occur as if this was null then the compareTo method call would never be reached (either by handling the exception or it being thrown). But by using nullsFirst I suppose if the argument passed in, i.e. other, was null, then this would handle this safely?
Many thanks in advance for any help.

Answer 1

Objects.compare is not meant to provide a null safe comparison, since there is no default behavior that could be implemented. It just implements a shortcut of not invoking the Comparator’s method when both objects are identical. In other words, it does a==b? 0: c.compare(a, b), nothing more. So not breaking when both objects are null is just a side-effect. The encapsulated code might look trivial but the other methods in this class are of a similar category. Using small utility methods a lot might still result in a notable win.
By the way, it’s not a Java 8 method at all. It exists since Java 7.
Regarding your second question, Comparator.nullsFirst(…) decorates an existing Comparator and will enforce the rule for null values before delegating to the provided comparator as it is the purpose of this comparator to shield the existing one from ever seeing null values. It doesn’t matter whether the decorated comparator is a chained one or not. As long as it is what you called the “inner comparator”, as
you must not invoke thenComparing on the result of nullsFirst as that would imply calling the next comparator when both values are null.
Comparator.nullsFirst(Comparator.comparing(a).thenComparing(b)) // perfect
Comparator.nullsFirst(Comparator.comparing(a)).thenComparing(b) // ouch
Now to your third question, implementing a compareTo method using a nullsFirst comparator is violating the interface specification:
The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)
This implies that passing null as argument should always result in a NullPointerException as swapping argument and receiver would throw as well, unconditionally.
Orders including a null policy should always be provided as separate Comparators.
Note that it would also be quite inefficient as you would create a new Comparator (multiple Comparators, to be precise) for every compareTo call. Now image sorting a rather large list of these objects…

Answer 2

What I normally do for your final question is to first create a static comparator reference within the class:
public static final Comparator<Song> COMP_DEFAULT
= nullsFirst(comparing(Song::getTitle, nullsFirst(naturalOrder()))
.thenComparing(Song::getArtist, nullsFirst(naturalOrder()))
.thenComparingInt(Song::getDuration));
And then refer to this comparator in compareTo
public int compareTo(Song other) {
return COMP_DEFAULT.compare(this, other);
}
This way you're not recreating your comparator for each compareTo call, null safety of Song is guaranteed as is the result of a.comparetTo(b) == b.compareTo(a).
We also ensure null safety of each property by using nullsFirst(naturalOrder()) for the passed in key comparator (second argument).
As the Comparator returned is immutable it can be made public which can be handy for bundling some alternate Comparators with the class that consumers may use.