Would this sorting algorithm work?

Question

I'm writing a sorting algorithm for a class that implements the Comparable interface. The class (called Memo) has a field, 'entryDate' of type 'Date', which itself has int fields for day, month, and year. I want to have the class sorted by date, earliest to latest, and then (for entries on the same day) by 'priority' (a field of type int; can be 1, 2 or 3).
The one I've written seems to work based on a few tests, but I just want to make sure it will work all the time:
(btw, i have to use the 'getEntryDate()' method because entryDate is a private field in the Memo class' superclass.
public int compareTo(Memo memo)
int comparison = getEntryDate().getYear() - memo.getEntryDate().getYear();
if(comparison != 0) {
return comparison;
comparison = getEntryDate().getMonth() - memo.getEntryDate().getMonth();
if(comparison != 0) {
return comparison;
comparison = getEntryDate().getDay() - memo.getEntryDate().getDay();
if(comparison != 0) {
return comparison;
return priority - memo.priority;
}

Answer 1

Generally when you simply subtract one int value from another in the compareTo() method, you'll have to take care that you don't run into an overflow situation (because comparing Integer.MIN_VALUE and (Integer.MIN_VALUE-1) would result in unpleasant surprises otherwise). But in your case you can probably safely assume that all your values are well within the safe range for int.
Also: If you have the chance to modify the Date chance I'd simply make the Date implement Comparable<Date> and delegate that comparison to the Date class.
Also: are two Memos at the same date with the same priority considered equal? Don't they have any other fields? It's important that objects that are not equals (i.e. a.equals(b) returns false) don't compare to be the same (i.e. a.compareTo(b) should only return 0 iff a.equals(b) returns true). Otherwise you might run into situations where objects are silently dropped because some Collection classes consider them to be equal (SortedSet implementations are tricky here).