Add (experimental) support of java.lang.Comparable

[GoogleCodeExporter]

What steps will reproduce the problem?

Implementing java.lang.Comparable for standard cases can be fastidious, because 
the calculation of the int return value might follow the same scheme as the 
ones used for the equals and hashCode (using each field, comparing, so on...)

What is the expected output? What do you see instead?

Provide an annotation to auto-generate the code for a basic appropriate 
compareTo() method in order to implement the java.lang.Comparable interface.
Provide this Lombok annotation with the same kind of attributes as the 
@EqualsAndHashCode one (esp. the "exclude" one, maybe "callSuper" and 
"doNotUseGetters" too)

Original issue reported on code.google.com by maxx...@gmail.com on 20 Dec 2012 at 4:14

[GoogleCodeExporter]

It's on our todo-list, but we want to take a somewhat wider view of this 
problem and introduce a more general annotation that indicates a complete 
strict relationship (so, it would also create compatible equals and hashCode 
methods and the name of the annotation will be a bit less unwieldy than 
@EqualsAndHashCode). The biggest issue is ordering the fields, and being able 
to supply small comparator properties for each field, such as 'reverse 
direction on this'. We can't go overboard with that obviously (at that point, 
it's not really boilerplate anymore), and we also need to worry about what we 
do if any given field is not of a type we implicitly know how to order, and 
also isn't Comparable. More to the point perhaps to know if the field is 
comparable in the first place we need to resolve type on it and that's very 
difficult to do in a handler that needs to create methods. Not impossible 
(@Delegate does it!) but it always leads to lots of complications.

Generics also don't help.

Original comment by reini...@gmail.com on 11 Mar 2013 at 11:33

[GoogleCodeExporter]

I'd suggest to look for the uses of Guava's ComparisonChain. I'm afraid there's 
no easy solution for anything which is neither primitive nor Comparable; not 
even for arrays (IIRC my most recent Comparator ordered int[] lexicographically 
as unsigned with the exception of ordering shorter arrays first - surely not 
something you want to create a syntax for).

Concerning the fields order, I believe that processing them as they appear in 
the source code is nearly sufficient except for you often want to skip a field 
(e.g. `id`) entirely or process it later. So maybe something like 
@Comparator.Postpone and @Comparator.Exclude would do (all the postponed fields 
would get processed after all normal fields, again in their appearance order).

Maybe you should assume that all non-primitive fields are Comparable and get a 
compile-time error if they're not. The user could annotate the field with 
@Comparator.UseComparator(MyComparator.class) to prevent this or to specify a 
special handling for Comparables.

It gets a bit complicated concerning the number of annotations, but it's fairly 
regular and need no hacks and no resolution. Finally, I'd also add 
@Comparator.Reverse and maybe @Comparator.NullFirst and @Comparator.NullLast.

Original comment by Maaarti...@gmail.com on 7 Dec 2013 at 11:09