java - 为什么这个带有绑定(bind)的泛型方法可以返回任何类型？

Question

为什么下面的代码会编译？IElement.getX(String) 方法返回 IElement 类型或其子类的实例。 Main 类中的代码调用 getX(String) 方法。编译器允许将返回值存储到 Integer 类型的变量中(这显然不在 IElement 的层次结构中)。

public interface IElement extends CharSequence {
  <T extends IElement> T getX(String value);
}

public class Main {
  public void example(IElement element) {
    Integer x = element.getX("x");
  }
}

返回类型是否应该仍然是 IElement 的实例 - 即使在类型删除之后？

getX(String)方法的字节码是:

public abstract <T extends IElement> T getX(java.lang.String);
flags: ACC_PUBLIC, ACC_ABSTRACT
Signature: #7                           // <T::LIElement;>(Ljava/lang/String;)TT;

编辑:将 String 替换为 Integer。

Answer 1

这实际上是一个合法的类型推断*。

我们可以将其简化为以下示例 (Ideone):

interface Foo {
    <F extends Foo> F bar();
    
    public static void main(String[] args) {
        Foo foo = null;
        String baz = foo.bar();
    }
}

允许编译器推断出(实际上是荒谬的)交集类型String & Foo因为Foo是一个接口(interface)。对于问题中的示例，Integer & IElement是推断出来的。

这很荒谬，因为转换是不可能的。我们不能自己做这样的 Actor :

// won't compile because Integer is final
Integer x = (Integer & IElement) element;

---

类型推断基本上适用于:

• 为每个方法的类型参数提供一组推理变量。
• 一组必须遵守的界限。
• 有时约束，它们被缩减到界限。

在算法结束时，每个变量解析为基于绑定(bind)集的交集类型，如果它们有效，则调用编译。

流程从 8.1.3 开始:

When inference begins, a bound set is typically generated from a list of type parameter declarations P<sub>1</sub>, ..., P<sub>p</sub> and associated inference variables α<sub>1</sub>, ..., α<sub>p</sub>. Such a bound set is constructed as follows. For each l (1 ≤ l ≤ p):

• […]

• Otherwise, for each type T delimited by & in a TypeBound, the bound α<sub>l</sub> <: T[P<sub>1</sub>:=α<sub>1</sub>, ..., P<sub>p</sub>:=α<sub>p</sub>] appears in the set […].

所以，这意味着首先编译器从 F <: Foo 的边界开始。 (这意味着 F 是 Foo 的子类型)。

移至 18.5.2 ，返回目标类型被考虑:

If the invocation is a poly expression, […] let R be the return type of m, let T be the invocation's target type, and then:

• […]

• Otherwise, the constraint formula ‹R θ → T› is reduced and incorporated with [the bound set].

约束公式‹R θ → T›减少到 R θ <: T 的另一个界限，所以我们有 F <: String .

稍后根据 18.4 解决这些问题:

[…] a candidate instantiation T<sub>i</sub> is defined for each α<sub>i</sub>:

• Otherwise, where α<sub>i</sub> has proper upper bounds U<sub>1</sub>, ..., U<sub>k</sub>, T<sub>i</sub> = glb(U<sub>1</sub>, ..., U<sub>k</sub>).

The bounds α<sub>1</sub> = T<sub>1</sub>, ..., α<sub>n</sub> = T<sub>n</sub> are incorporated with the current bound set.

回想一下，我们的边界集是 F <: Foo, F <: String . glb(String, Foo)定义为 String & Foo .这显然是 glb 的合法类型，只需要:

It is a compile-time error if, for any two classes (not interfaces) V<sub>i</sub> and V<sub>j</sub>, V<sub>i</sub> is not a subclass of V<sub>j</sub> or vice versa.

最后:

If resolution succeeds with instantiations T<sub>1</sub>, ..., T<sub>p</sub> for inference variables α<sub>1</sub>, ..., α<sub>p</sub>, let θ' be the substitution [P<sub>1</sub>:=T<sub>1</sub>, ..., P<sub>p</sub>:=T<sub>p</sub>]. Then:

• If unchecked conversion was not necessary for the method to be applicable, then the invocation type of m is obtained by applying θ' to the type of m.

因此使用 String & Foo 调用该方法作为 F 的类型.我们当然可以将其分配给 String ，因此不可能转换 Foo到 String .

String 的事实/Integer显然没有考虑最终类。

---

_{* 注意:类型 erasure 与问题完全无关。}

_{此外，虽然它也可以在 Java 7 上编译，但我认为我们不必担心那里的规范是合理的。 Java 7 的类型推断本质上是 Java 8 的一个不太复杂的版本。它编译的原因类似。}

---

作为附录，虽然很奇怪，但这可能永远不会导致尚未出现的问题。编写一个返回类型仅从返回目标推断的泛型方法很少有用，因为只有 null可以从这样的方法返回而无需强制转换。

例如，假设我们有一些 map 类比，它存储特定接口(interface)的子类型:

interface FooImplMap {
    void put(String key, Foo value);
    <F extends Foo> F get(String key);
}

class Bar implements Foo {}
class Biz implements Foo {}

出现如下错误已经完全有效:

FooImplMap m = ...;
m.put("b", new Bar());
Biz b = m.get("b"); // casting Bar to Biz

所以我们可以也做Integer i = m.get("b");不是 新 的错误可能性。如果我们像这样编写代码，那么一开始就可能不合理。

一般来说，类型参数应该仅在没有理由绑定(bind)它的情况下从目标类型推断出来，例如Collections.emptyList()和 Optional.empty() :

private static final Optional<?> EMPTY = new Optional<>();

public static<T> Optional<T> empty() {
    @SuppressWarnings("unchecked")
    Optional<T> t = (Optional<T>) EMPTY;
    return t;
}

这没问题，因为 Optional.empty()既不能生产也不能消费T .