关于comparable接口的说法是否正确，大家看下。。

Question

  Comparable 接口由Collections.sort()方法用来排序List。
Collections类的API里没有说实现了这个接口。

Answer 1

看看java的api，找找这个接口是干什么的。你这样的书法似乎不对。这是比较器接口。

Answer 2

此接口强行对实现它的每个类的对象进行整体排序。此排序被称为该类的自然排序，类的 compareTo 方法被称为它的自然比较方法。实现此接口的对象列表（和数组）可以通过 Collections.sort（和 Arrays.sort）进行自动排序。实现此接口的对象可以用作有序映射表中的键或有序集合中的元素，无需指定比较器。对于类 C 的每一个 e1 和 e2 来说，当且仅当 (e1.compareTo((Object)e2) == 0) 与 e1.equals((Object)e2) 具有相同的布尔值时，类 C 的自然排序才叫做与 equals 一致。注意，null 不是任何类的实例，即使 e.equals(null) 返回 false，e.compareTo(null) 也会抛出 NullPointerException。强烈推荐（虽然不是必需的）使自然排序与 equals 一致。这是因为在使用其自然排序与 equals 不一致的元素（或键）时，没有显式比较器的有序集合（和有序映射表）行为表现“怪异”。尤其是，这样的有序集合（或有序映射表）违背了根据 equals 方法定义的集合（或映射表）的常规协定。例如，如果将两个键 a 和 b 添加到一个没有使用显式比较器的有序集合中，使得 (!a.equals((Object)b) && a.compareTo((Object)b) == 0)，则第二个 add 操作返回 false（有序集合的大小没有增加），因为从有序集合的角度来看，a 和 b 是等效的。实际上，所有执行比较的 Java 核心类都具有 equals 一致的自然排序。java.math.BigDecimal 是个例外，它的自然排序把值相等但精确度不同的 BigDecimal 对象（比如 4.0 和 4.00）等同起来。为了向数学上倾斜，在给定 C 类的基础上定义自然排序的关系 如下：      {(x, y) such that x.compareTo((Object)y) <= 0}。
整体排序的 quotient 是：
      {(x, y) such that x.compareTo((Object)y) == 0}。
它直接遵循 compareTo 的协定，商是 C 的等价关系，自然排序是 C的整体排序。当我们说类的自然排序与 equals 一致 时，是指自然排序的商是由类的 equals(Object) 方法定义的等价关系。
    {(x, y) such that x.equals((Object)y)}。

Answer 3

Collections这个类没有实现Comparable接口。

Answer 4

汗，
Collections.sort(list,new Comparable(){})；
是这样用的！

Answer 5

Comparable? Comparator?
public static <T extends Comparable<? super T>> void sort(List<T> list)
public static <T> void sort(List<T> list, Comparator<? super T> c)

Answer 6

不好意思看错接口了。
Collections.sort(list,new Comparator(T){})；

Answer 7

是Comparator接口吧，不是Comparable

Answer 8

还有，实现了comparable接口的类，其对象可以作为SortedMap的key，或者SortedSet的元素。实现其compare（T o1,T o2）有一个约定，就是 a.compare(b) == 0 和a.equals(b)要有相同的boolean结果。具体看API，或者Effective java第12条

Answer 9

原来是说sort(集合）这个集合里边的类必须 实现 Comparable接口，
那为什么String可以不要实现

Answer 10

Comparable：实现这个接口说明你的类是“可比较”的，“对象之间可比较”是个附加功能；
Comparator：实现这个接口说明你的类是一种 “比较器”，其主要功能应该作为一个比较器。
以上个人愚见，不对之处请指正。