用“super”限制泛型关键词

Question

为什么我只能将 super 与通配符一起使用，而不能与类型参数一起使用？

比如Collection接口中，为什么toArray方法不这么写

interface Collection<T>{
    <S super T> S[] toArray(S[] a);
}

Answer 1

super 绑定命名类型参数（例如 ），而不是通配符（例如 ) 是非法，只是因为即使允许，它也不会执行您希望它执行的操作，因为 Object 是最终的super 所有引用类型，并且一切都是一个 Object，实际上没有绑定。

在您的具体示例中，由于任何引用类型的数组都是Object[]（通过Java数组协方差），因此它可以用作<的参数;S超级T> S[] toArray(S[] a) （如果这样的绑定是合法的）在编译时，并且它不会在运行时阻止 ArrayStoreException 。

你试图提出的是给定：

List<Integer> integerList;

并且给定这个假设super绑定在toArray上：

<S super T> S[] toArray(S[] a) // hypothetical! currently illegal in Java

编译器应该只允许编译以下内容:

integerList.toArray(new Integer[0]) // works fine!
integerList.toArray(new Number[0])  // works fine!
integerList.toArray(new Object[0])  // works fine!

并且没有其他数组类型参数（因为 Integer 只有这 3 种类型作为 super）。也就是说，您试图阻止此编译：

integerList.toArray(new String[0])  // trying to prevent this from compiling

因为根据您的说法，String 不是 Integer 的super。 但是，Object 是 Integer 的 super，而 String[] 是一个 Object[]，因此编译器仍然会让上面的代码编译，即使假设你可以！

因此，以下仍然会编译（就像它们现在的样子一样），并且运行时的ArrayStoreException无法通过使用泛型类型的任何编译时检查来阻止边界：

integerList.toArray(new String[0])  // compiles fine!
// throws ArrayStoreException at run-time

泛型和数组不混合，这是它显示的许多地方之一。

---

一个非数组示例

再次，假设您有这个泛型方法声明：

<T super Integer> void add(T number) // hypothetical! currently illegal in Java

并且您有这些变量声明：

Integer anInteger
Number aNumber
Object anObject
String aString

您使用 （如果合法）的意图是它应该允许add(anInteger) 和 add(aNumber)，当然还有 add(anObject)，但不是 add(aString)< /代码>。好吧，String 是一个 Object，因此 add(aString) 无论如何仍然可以编译。

---

另请参阅

• Java 教程/泛型
  • 子类型
  • 使用通配符更有趣

相关问题

关于泛型输入规则：

• 任何简单的方法来解释为什么我不能这样做 列表<动物> Animals = new ArrayList()?
• Java 泛型（非）协方差
• 什么是原始类型以及为什么我们不应该使用它吗？
  • 解释原始类型 List 与 List

在使用 < code>super 和 extends：

• Java 泛型：什么是PECS？
  • 来自Effective Java 2nd Edition：“生产者扩展消费者超级”
• super 和 extends 之间有什么区别Java泛型
• 有什么区别 和 ？
• 如何添加到列表<？扩展 Number> 数据结构？（你不能！）

Answer 2

由于没有人提供满意的答案，正确的答案似乎是“没有充分的理由”。

Polygenelubricants 很好地概述了 java 数组协方差所发生的不良情况，这本身就是一个可怕的功能。考虑下面的代码片段：

String[] strings = new String[1];
Object[] objects = strings;
objects[0] = 0;

这个明显错误的代码编译时没有诉诸任何“超级”构造，因此数组协方差不应该用作参数。

现在，我在这里有一个完全有效的代码示例，需要在命名类型参数中使用 super：

class Nullable<A> {
    private A value;
    // Does not compile!!
    public <B super A> B withDefault(B defaultValue) {
        return value == null ? defaultValue : value;
    }
}

潜在地支持一些不错的用法：

Nullable<Integer> intOrNull = ...;
Integer i = intOrNull.withDefault(8);
Number n = intOrNull.withDefault(3.5);
Object o = intOrNull.withDefault("What's so bad about a String here?");

如果我删除 B 总共，所以确实需要 B 。

请注意，如果我反转类型参数声明的顺序，从而将 super 约束更改为 extends，那么我尝试实现的功能很容易获得。然而，只有当我将该方法重写为静态方法时，这才有可能：

// This one actually works and I use it.
public static <B, A extends B> B withDefault(Nullable<A> nullable, B defaultValue) { ... }

关键是，这种 Java 语言限制确实限制了一些原本可能有用的功能，并且可能需要丑陋的解决方法。我想知道如果我们需要 withDefault 是虚拟的，会发生什么。

现在，为了与 polygenelubricants 所说的相关联，我们在这里使用 B 不是为了限制作为 defaultValue 传递的对象类型（请参阅示例中使用的字符串），而是为了限制调用者对我们返回的对象的期望。作为一个简单的规则，您可以将 extends 与您需要的类型一起使用，将 super 与您提供的类型一起使用。

Answer 3

您的问题的“官方”答案可以在 Sun/Oracle 错误报告。

BT2：评估

查看

http://lampwww.epfl.ch/~odersky/ftp/本地ti.ps

特别是第 3 节和第 9 页的最后一段。
子类型约束两侧的类型变量可能会导致
没有单一最佳解的类型方程组；最后，
无法使用任何现有标准来完成类型推断
算法。这就是为什么类型变量只有“扩展”界限。

另一方面，通配符不必进行推断，因此
不需要这个约束。

@###.### 2004-05-25

是的；关键点是通配符，即使被捕获，也仅被使用
作为推理过程的输入；没有（仅）下限需求
从而推断出结果。

@###.### 2004-05-26

我看到了问题。但我不明白它与问题有什么不同
我们在推理过程中对通配符有下限，例如：

列表 s;
布尔值 b;
...
s = b ? s：s；

目前，我们推断 List其中 X 扩展了 Object 作为
条件表达式，表示赋值非法。

@###.### 2004-05-26

遗憾的是，谈话到此结束。 （现已失效）链接所指向的论文是 GJ 的推断类型实例化< /a>.从最后一页来看，它可以归结为：如果允许下限，类型推断可能会产生多个解决方案，其中没有一个是 校长。

Answer 4

唯一的原因是在类级别定义时使用 super 关键字声明类型参数是没有意义的。
Java 唯一合乎逻辑的类型擦除策略是回退到所有对象的超类型，即 Object 类。

可以在这里找到一个很好的示例和解释：
http: //www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#为什么%20is%20there%20no%20lower%20bound%20for%20type%20parameters？

类型擦除规则的简单示例可以在这里找到：
https://www.tutorialspoint.com/java_generics/java_generics_type_erasure.htm#:~:text=Type%20erasure%20is%20a%20process,there%20is%20no%20runtime%20overhead。

Answer 5

假设我们有：

• 基本类 A > B＞ C和D

  <前><代码>A类{
  无效方法A(){}
  };
  B 类扩展 A{
  无效方法B(){}
  }

  C 类扩展 B{
  void 方法C(){}
  }

  D 类{
  无效方法D(){}
  }

• 作业包装类

  接口Job; {
      无效执行（T t）；
  }
  
  JobOnA 类实现 Job{
      @覆盖
      公共无效执行（A a）{
          a.methodA();
      }
  }
  类 JobOnB 实现 Job{
      @覆盖
      公共无效执行（B b）{
          b.methodB();
      }
  }
  
  JobOnC 类实现 Job{
      @覆盖
      公共无效执行（CC）{
          c.methodC();
      }
  }
  
  JobOnD 类实现 Job{
      @覆盖
      公共无效执行（D d）{
          d.methodD();
      }
  }
  

• 和一个管理器类，具有 4 种不同方法在对象上执行作业

  类管理器{
      最终T t；
      经理(T t){
          这个.t=t;
      }
      公共无效执行1（作业作业）{
          作业.exec(t);
      }
  
      公共无效执行2（作业作业）{
          Uu=(U)t； //不安全
          作业.exec(u);
      }
  
      公共 voidexecute3(Job job){
          Uu=(U)t； //不安全
          作业.exec(u);
      }
  
      //所需的功能，暂时未编译
      公共无效execute4（作业作业）{
          Uu=(U)t； //安全的
          作业.exec(u);
      }
  }
  

• 和用法

  无效用法(){
      B b = 新 B();
      经理 managerB = 新的 Manager(b);
  
      //太严格了
      managerB.execute1(new JobOnA());
      managerB.execute1(new JobOnB()); //编译完成
      managerB.execute1(new JobOnC());
      managerB.execute1(new JobOnD());
  
      //太多的自由
      managerB.execute2(new JobOnA()); //编译完成
      managerB.execute2(new JobOnB()); //编译完成
      managerB.execute2(new JobOnC()); //编译完成！！
      managerB.execute2(new JobOnD()); //编译完成！！
  
      //限制不够     
      managerB.execute3(new JobOnA());
      managerB.execute3(new JobOnB()); //编译完成
      managerB.execute3(new JobOnC()); //编译完成！！
      managerB.execute3(new JobOnD());
  
      //应该是
      managerB.execute4(new JobOnA()); //编译完成
      managerB.execute4(new JobOnB()); //编译完成
      managerB.execute4(new JobOnC());
      managerB.execute4(new JobOnD());
  }
  

现在对如何实现execute4有什么建议吗？

==========编辑=======

    public void execute4(Job<? super  T> job){
        job.exec( t);
    }

感谢大家:)

==========编辑==========

    private <U> void execute2(Job<U> job){
        U u= (U) t;  //now it's safe
        job.exec(u);
    }
    public void execute4(Job<? super  T> job){
        execute2(job);
    }

好多了，任何代码U 里面的execute2

超类型U 被命名！

有趣的讨论:)

Answer 6

我真的很喜欢这个被接受的答案，但我想对此提出稍微不同的观点。

类型化参数中支持 super 仅是为了允许逆变功能。当谈到协方差和逆变时，了解Java仅支持使用站点方差非常重要。与 Kotlin 或 Scala 不同，它们允许声明站点差异。 Kotlin 文档此处对此进行了很好的解释。或者，如果您更喜欢 Scala，这里给你一份。

它基本上意味着在 Java 中，当您根据 PECS 声明类时，您不能限制类的使用方式。该类既可以消费又可以生产，并且它的一些方法可以同时执行此操作，例如 toArray([]) 顺便说一句。

现在，在类和方法声明中允许使用 extends 的原因是，它更多的是关于多态性，而不是变异。一般来说，多态性是 Java 和 OOP 的固有部分：如果方法可以接受某些超类型，则始终可以安全地将子类型传递给它。如果一个方法，在声明站点因为它是“契约”，应该返回一些超类型，那么如果它在其实现中返回一个子类型，那就完全没问题了