Why does the Java Collections Framework offer two different ways to sort?

Question

If I have a list of elements I would like to sort, Java offers two ways to go about this.

For example, lets say I have a list of Movie objects and I’d like to sort

Answer 1

It depends who controls the ordering. If the ordering of an object is an implementation detail of the object, the Comparable is more appropriate. If the ordering of the objects is controlled by the caller, then Comparator is more appropriate.

Answer 2

One is for conciseness for what should be a common case (Effective Java 2nd Edition, Item 12: Consider implementing Comparable). The other, as you noted, is for flexibility and general-purposeness.

Related questions

• difference between compare() and compareTo()
• When to use Comparable vs Comparator
• Comparable and Comparator contract with regards to null
• Can I use a Comparator without implementing Comparable?

Answer 3

I'm not sure I find it that odd. I have a list of things to sort that have a natural order like numbers. Do I really expect I have to tell the API how to compare numbers? I wouldn't look for a two-arg method, intuitively. Thus Comparable exists.

But of course you can and should be able to define a different ordering, thus the other method. For example, even though numbers have a natural ordering, I may still want a different ordering: for example, order by value descending. Thus Comparator exists.

And of course some things don't have a natural ordering like Fruit, but you might still wish to order a list of them. Thus Comparator, again.