Java:关于 Collections ReverseComparator 的实现

Question

实现如下(jdk1.6.0_31):

private static class ReverseComparator<T>
implements Comparator<Comparable<Object>>, Serializable {

// use serialVersionUID from JDK 1.2.2 for interoperability
private static final long serialVersionUID = 7207038068494060240L;

    public int compare(Comparable<Object> c1, Comparable<Object> c2) {
        return c2.compareTo(c1);
    }

    private Object readResolve() { return reverseOrder(); }
}

为什么不能改为如下实现:

private static class ReverseComparator<T extends Comparable<T>> 
implements Comparator<T>, Serializable {

// use serialVersionUID from JDK 1.2.2 for interoperability
private static final long serialVersionUID = 7207038068494060240L;

    public int compare(T c1, T c2){
        return c2.compareTo(c1);
    }
    ...
}

这只是风格，还是有更深层次的原因？

编辑:显示的源代码来自 Sun/Oracle jdk ((jdk1.6.0_31))。

Answer 1

我相信这都与使 ReverseComparator 成为单例对象的意图有关。由于必须在静态上下文中定义单例实例，因此没有必要使用任何泛型类型。

static final ReverseComparator REVERSE_ORDER = new ReverseComparator();

此代码生成原始类型警告。

因此，仅用于此问题的 ReverseComparator 的实现可能与您建议的或已实现的一样。也许他们选择当前实现是因为它更易于阅读，并且因为他们认为如果只是为了这个简单的目的私下使用，则不需要进一步概括。

在您的实现和 Oracle 的实现上运行 Java 反编译器会生成相同的原始类型字节代码。

 public int compare(java.lang.Comparable, java.lang.Comparable
 public int compare(java.lang.Object, java.lang.Object);

最后，当比较器在reverseOrder() 方法中通过Collections 类的公共(public)接口(interface)暴露时，无法避免强制转换和unchecked 警告。但我们都确信，无论涉及何种类型，这都不会失败。

最重要的是，恕我直言，我认为它之所以按原样实现的唯一原因与代码清晰度有关，或者是希望不要使事情变得不必要地复杂化，无论如何，无法避免未经检查的警告。但是，嘿，这不是我第一次错了 ;-)