Those are two different functionalities.
Comparable denotes: "I can compare myself against another object of my kind".
Comparator says: "I know how to compare two objects of a certain kind".
Those are different use cases - and you simply want both - just for different situations.
Example: when you want to sort some objects that are coming from an external library. The corresponding class does not implement Comparable - but you can still sort them by providing a Comparator.
Another example: assume you have a list of objects that have various attributes. Now you can create different Comparators for that one class; and each one compares a different field - allowing you to sort a List<Person>
on Person.getName(), or Person.getAge(), ...
On the other hand, you have classes like Integer - where it simply makes sense that one Integer knows how to compare itself against another Integer. Simply because the natural order of numbers should be a part of your object model as well.
Beyond that: it seems that you don't get my point. Thing is: those two concepts are simple two different abstractions. Of course you can build something complicated that expresses what the one concept does in terms of the other concept. But that is like using a hammer to get a screw into the wall. It simply creates more problems than it will be solving. Your suggestion to have another class implement Comparable in order to sort in a different way - boils down to instantiate one addition object per list entry. Not efficient at all. And also very much counter intuitive for any experienced Java programmer. You don't invent your own wheel unless you have to. And you forget about inventing your own wheel when it is clear right from scratch that this wheel will be deficient compared to the already existing, well known and widely used wheel.