这两个Collections.binarySearch的通用签名有何不同？

Question

这是Java中Collections.binarySearch的定义：

static <T> int binarySearch(List<? extends Comparable<? super T> list, T key)
static <T> int binarySearch(List<? extends T> list, T key, Comparator<? super T> c)

它们与以下定义（与Collections.sort相似）有何不同：

static <T extends Comparable<? super T>> int binarySearch(List<T> list, T key)
static <T> int binarySearch(List<T>, T x, Comparator<? super T>)

据我了解：

第一个定义使您可以在值列表中搜索类型T的键，这些键的类型与某个类型的“低”类型相同，或者知道该类型如何比较T类型的实例或某个“上方”类型的实例。

第二个定义使您可以使用比较器来搜索值列表中类型T的键，该值的类型与类型T相同或“低于”类型的Comparator知道如何比较类型T的实例或某些“上方”类型的实例。

基本上，我不理解的是为什么为什么列表内容不被强制具有与键相同的类型？

Answer 1

第一组签名较为笼统。 它适用于奇数边缘情况，第二种情况会拒绝。 考虑以下情况

 import java.sql.Timestamp;  // extends Date implements Comparable<Date> (!)
 import java.util.Date;

 List<Timestamp> timestamps = ...;
 Date key = ...;
 int index = Collections.binarySearch(timestamps, key);

这适用于第一个签名，但在第二个签名下将被视为类型错误（您必须先将key转换为Timestamp ）。

这可能很少见，但是如Timestamp和Date的示例所示，JDK中有一些示例。

也许，这有助于记住， binarySearch永远不需要将列表的元素与列表的其他元素进行比较。 它只将列表的元素与给定的key进行比较，因此，有必要要求列表元素与key （而不是彼此）具有可比性。