英文:
why is a component in the error report for generic method call bounded?
问题
在《Java核心技术卷1》中，Horstmann推荐了Peter von der Ahé的这个技巧，即“故意引入一个错误...以查看编译器为泛型方法调用推断出哪种类型”。
例如，对于以下代码：
//class ArrayAlg
public static <T> T getMiddle(T...a) {
return a[a.length/2];
}
将结果分配如下：
JButton aButton = ArrayAlg.getMiddle("Hello", 0, null);
将会产生以下错误报告：
found:
java.lang.Object&java.io.Serializable&java.lang.Comparable<?
extends java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>
Horstmann解释说：“用简单的英语来说，你可以将结果分配给Object、Serializable或Comparable。”
问题：
我不理解错误报告的最后一部分...&java.lang.Comparable<? extends java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>。
为什么有Comparable组件的边界？
英文:
In 'Core Java Volume 1', Horstmann recommends this trick from Peter von der Ahé to "purposely introducing an error ... to see which type the compiler infers for a generic method call".
For example, for:
//class ArrayAlg
public static <T> T getMiddle(T...a) {
return a[a.length/2];
}
Assigning the result as such:
JButton aButton = ArrayAlg.getMiddle("Hello", 0, null);
will give an error report of:
found:
java.lang.Object&java.io.Serializable&java.lang.Comparable<? extends
java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>
which Horstmann explains: "In plain English, you can assign the result to Object, Serializable, or Comparable.
Question:
I don't understand the last part of the error report ...&java.lang.Comparable<? extends java.lang.Object&java.io.Serializable&java.lang.Comparable<?>>.
Why is there a bound for Comparable component?
答案1
得分: 0
"为什么
Comparable组件有界限？"
TL;DR — 这很复杂。但我很简单地想：所有三者都被报告，因为String（也叫做，T，又叫做“Hello”） 实现了所有三个接口。
详细版本
您看到的是编译器三个类型推断过程之一失败的结果。
基本上，类型推断试图弄清楚：“嗯，T可能是什么类型？”。它确定_T_是某种数组。
然后它必须弄清楚，该_Array_中元素的具体类型是什么。为了回答这个问题，它检查了泛型方法的参数。它对于兼容性提出了断言：“由于第一个参数的类型是String，而且我已经知道我正在处理一个Array —— 而且Array总是保存相同的类型 —— 那么其他两个参数在逻辑上也必须是String类型”。
然后，它进行了编译器等价于查看Javadoc的操作，以确定_String与Object＆Serializable＆Comparable_是兼容的。
这是为什么您在错误消息中看到了_Comparable_和其他两个组件的高级“用通俗的英语来说”概述。如果需要详细信息，请阅读我上面链接的JLS章节。
英文:
> „…Why is there a bound for Comparable component?…“
TL;DR — It's complicated. But I think of it very simply: All three are reported because String (aka, T, aka "Hello") implements all three.
The long version
You're seeing the result of a failure of one of the compiler's three type inference processes.
Essentially, type inference tries to figure out: „Hmm, now what type could T be?“. It determines that T is an Array of something.
Then it has to figure out, what the specific type of the elements of that Array is. To answer that, it examines the generic method's argument(s). It makes an assertion about compatibilty: „Since the first argument is of type String, and since I already know I'm dealing with an Array — and Arrays always hold the same type — then the other two arguments, logically, must also be of type String“.
Then it does the compiler equivalent of looking at the Javadoc to figure out that String is compatible with Object & Serializable & Comparable.
That's the high-level „In plain English“ overview of why you're seeing Comparable and the other two in your error message. Read the chapter of the JLS I linked to above if you need the gory details.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论