为什么T在Collections.max（）签名中受Object约束？ [英] Why is T bounded by Object in the Collections.max() signature?

问题描述

刚刚完成了Java 7的 java.util.Collections 类的实现，并看到了一些我不明白的东西。在 max 函数签名中，为什么 T 以 Object ？



  public static< T extends Object&可比< ;? super T>> T max（Collection<？extends T> coll）{
 Iterator<延伸T>我= coll.iterator（）; 
 T candidate = i.next（）; 
 
 while（i.hasNext（））{
 T next = i.next（）; 
 if（next.compareTo（candidate）> 0）
 candidate = next; 
} 
回报候选人; 
} 
  

max 似乎

  public static< T extends Comparable< ;? super T>> T max（Collection<？extends T> coll）{
 Iterator<延伸T>我= coll.iterator（）; 
 T candidate = i.next（）; 
 
 while（i.hasNext（））{
 T next = i.next（）; 
 if（next.compareTo（candidate）> 0）
 candidate = next; 
} 
回报候选人; 
} 
  

实际上是否存在边界有差别的情况？如果是的话，请提供一个具体的例子。

解决方案

两者的边界相同，但 一个微妙的区别。 < / p>



 < T扩展了Object&可比< ;? super T>> 
  

这会导致 T 变成<



 < T扩展了Comparable< ;? code> Object  super T>> 
  

这将导致 T 变为<$

---

在这种情况下，它的完成是因为 Comparable c $ c> .max 早于Java 5.我们可以在这个链接 Joachim很好地提供了Java 1.4.2中 .max 的签名：

  public static Object max（Collection coll）
  

如果我们使用< T扩展Comparable< ;?超级T>> 作为绑定，我们的签名将是

  public static Comparable max coll）
  

这会破坏API。我已经设法找到这个页面，讨论将旧的API转换为通用的API，给出 .max 作为具体示例。

这里解释了为什么 max 是这样定义的：

您还需要确保修订后的API保持与旧客户端的二进制兼容性。这意味着API的删除必须与原始的未加密API相同。在大多数情况下，这种情况自然会消失，但也有一些微妙的情况。我们将检查我们遇到的一个最微妙的情况，方法 Collections.max（）。正如我们在通配符更多乐趣一节中看到的那样， max（）的可信签名是：

public static< T extends Comparable< ;? super T>> T max（Collection< T> coll）这很好，除了这个签名的擦除是： public static Comparable max（Collection coll）这与max（）的原始签名不同： public static Object max（Collection coll）

肯定已经为max（）指定了这个签名，但是它没有完成，所有调用Collections.max（）的旧二进制类文件都依赖于返回Object的签名。

Just went through the implementation of Java 7's java.util.Collections class, and saw something that I don't understand. In the max function signature, why is T bounded by Object?

public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll) {
    Iterator<? extends T> i = coll.iterator();
    T candidate = i.next();

    while (i.hasNext()) {
        T next = i.next();
        if (next.compareTo(candidate) > 0)
            candidate = next;
    }
    return candidate;
} 

max seems to work fine if the Object bound is omitted.

public static <T extends Comparable<? super T>> T max(Collection<? extends T> coll) {
    Iterator<? extends T> i = coll.iterator();
    T candidate = i.next();

    while (i.hasNext()) {
        T next = i.next();
        if (next.compareTo(candidate) > 0)
            candidate = next;
    }
    return candidate;
}

Are there actually any situations where the bound makes a difference? If yes, please provide a concrete example.

解决方案

The two have the same bounds but there is a subtle difference.

 <T extends Object & Comparable<? super T>> 

This will cause T to become an Object under erasure.

 <T extends Comparable<? super T>>

This will cause T to become Comparable under erasure.

---

In this case it is done because .max predates Java 5. We can see in this link Joachim kindly provided that the signature of .max in Java 1.4.2 is:

public static Object max(Collection coll)

Had we used <T extends Comparable<? super T>> as a bound, our signature would be

public static Comparable max(Collection coll)

Which would break the APIs. I've managed to find this page that discusses converting old APIs to generic ones and it gives .max as a specific example.

Here they explain why max is defined this way:

You also need to ensure that the revised API retains binary compatibility with old clients. This implies that the erasure of the API must be the same as the original, ungenerified API. In most cases, this falls out naturally, but there are some subtle cases. We'll examine one of the subtlest cases we've encountered, the method Collections.max(). As we saw in section More Fun with Wildcards, a plausible signature for max() is:

public static <T extends Comparable<? super T>> T max(Collection<T> coll) This is fine, except that the erasure of this signature is: public static Comparable max(Collection coll) which is different than the original signature of max(): public static Object max(Collection coll)

One could certainly have specified this signature for max(), but it was not done, and all the old binary class files that call Collections.max() depend on a signature that returns Object.

这篇关于为什么T在Collections.max（）签名中受Object约束？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！