java - 为什么类型参数比方法参数强

Question

为什么是

public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {...}

然后更严格

public <R> Builder<T> with(Function<T, R> getter, R returnValue) {...}

这是对 Why is lambda return type not checked at compile time 的跟进.
我发现使用方法 withX()喜欢

.withX(MyInterface::getLength, "I am not a Long")

产生想要的编译时错误:

The type of getLength() from the type BuilderExample.MyInterface is long, this is incompatible with the descriptor's return type: String

使用方法时 with()才不是。

完整示例:

import java.util.function.Function;

public class SO58376589 {
  public static class Builder<T> {
    public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {
      return this;
    }

    public <R> Builder<T> with(Function<T, R> getter, R returnValue) {
      return this;
    }

  }

  static interface MyInterface {
    public Long getLength();
  }

  public static void main(String[] args) {
    Builder<MyInterface> b = new Builder<MyInterface>();
    Function<MyInterface, Long> getter = MyInterface::getLength;
    b.with(getter, 2L);
    b.with(MyInterface::getLength, 2L);
    b.withX(getter, 2L);
    b.withX(MyInterface::getLength, 2L);
    b.with(getter, "No NUMBER"); // error
    b.with(MyInterface::getLength, "No NUMBER"); // NO ERROR !!
    b.withX(getter, "No NUMBER"); // error
    b.withX(MyInterface::getLength, "No NUMBER"); // error !!!
  }
}

javac SO58376589.java

SO58376589.java:32: error: method with in class Builder<T> cannot be applied to given types;
    b.with(getter, "No NUMBER"); // error
     ^
  required: Function<MyInterface,R>,R
  found: Function<MyInterface,Long>,String
  reason: inference variable R has incompatible bounds
    equality constraints: Long
    lower bounds: String
  where R,T are type-variables:
    R extends Object declared in method <R>with(Function<T,R>,R)
    T extends Object declared in class Builder
SO58376589.java:34: error: method withX in class Builder<T> cannot be applied to given types;
    b.withX(getter, "No NUMBER"); // error
     ^
  required: F,R
  found: Function<MyInterface,Long>,String
  reason: inference variable R has incompatible bounds
    equality constraints: Long
    lower bounds: String
  where F,R,T are type-variables:
    F extends Function<MyInterface,R> declared in method <R,F>withX(F,R)
    R extends Object declared in method <R,F>withX(F,R)
    T extends Object declared in class Builder
SO58376589.java:35: error: incompatible types: cannot infer type-variable(s) R,F
    b.withX(MyInterface::getLength, "No NUMBER"); // error
           ^
    (argument mismatch; bad return type in method reference
      Long cannot be converted to String)
  where R,F,T are type-variables:
    R extends Object declared in method <R,F>withX(F,R)
    F extends Function<T,R> declared in method <R,F>withX(F,R)
    T extends Object declared in class Builder
3 errors

扩展示例

以下示例显示了归结为供应商的方法和类型参数的不同行为。此外，它还显示了类型参数与消费者行为的差异。并且它表明它对于方法参数是消费者还是供应商没有区别。

import java.util.function.Consumer;
import java.util.function.Supplier;
interface TypeInference {

  Number getNumber();

  void setNumber(Number n);

  @FunctionalInterface
  interface Method<R> {
    TypeInference be(R r);
  }

  //Supplier:
  <R> R letBe(Supplier<R> supplier, R value);
  <R, F extends Supplier<R>> R letBeX(F supplier, R value);
  <R> Method<R> let(Supplier<R> supplier);  // return (x) -> this;

  //Consumer:
  <R> R lettBe(Consumer<R> supplier, R value);
  <R, F extends Consumer<R>> R lettBeX(F supplier, R value);
  <R> Method<R> lett(Consumer<R> consumer);


  public static void main(TypeInference t) {
    t.letBe(t::getNumber, (Number) 2); // Compiles :-)
    t.lettBe(t::setNumber, (Number) 2); // Compiles :-)
    t.letBe(t::getNumber, 2); // Compiles :-)
    t.lettBe(t::setNumber, 2); // Compiles :-)
    t.letBe(t::getNumber, "NaN"); // !!!! Compiles :-(
    t.lettBe(t::setNumber, "NaN"); // Does not compile :-)

    t.letBeX(t::getNumber, (Number) 2); // Compiles :-)
    t.lettBeX(t::setNumber, (Number) 2); // Compiles :-)
    t.letBeX(t::getNumber, 2); // !!! Does not compile  :-(
    t.lettBeX(t::setNumber, 2); // Compiles :-)
    t.letBeX(t::getNumber, "NaN"); // Does not compile :-)
    t.lettBeX(t::setNumber, "NaN"); // Does not compile :-)

    t.let(t::getNumber).be(2); // Compiles :-)
    t.lett(t::setNumber).be(2); // Compiles :-)
    t.let(t::getNumber).be("NaN"); // Does not compile :-)
    t.lett(t::setNumber).be("NaN"); // Does not compile :-)
  }
}

Answer 1

这是一个非常有趣的问题。恐怕答案很复杂。

tl;博士

找出差异需要深入阅读 Java 的 type inference specification。 ，但基本上归结为:

在所有其他条件相同的情况下，编译器可以推断出最具体的类型。

但是，如果它可以找到满足所有要求的类型参数的替换，那么编译就会成功，无论替换结果多么模糊。

对于 with有一个(公认的含糊不清的)替换满足 R 上的所有要求:Serializable

对于 withX ，引入附加类型参数F强制编译器解析 R首先，不考虑约束F extends Function<T,R> . R解析为(更具体的)String这意味着 F 的推断失败。

最后一个要点是最重要的，但也是最流行的。我想不出更简洁的措辞方式，所以如果你想了解更多细节，我建议你阅读下面的完整解释。

这是预期的行为吗？

我要出去走走，说不。

我并不是在暗示规范中有错误，更多的是(在 withX 的情况下)语言设计者举起手说“在某些情况下类型推断变得太难了，所以我们只会失败”。即使编译器的行为与 withX 有关似乎是您想要的，我认为这是当前规范的附带副作用，而不是积极的设计决策。

这很重要，因为它告知了问题 我应该在我的应用程序设计中依赖这种行为吗？ 我认为您不应该这样做，因为您无法保证该语言的 future 版本将继续以这种方式运行。

虽然语言设计者在更新规范/设计/编译器时确实非常努力地尝试不破坏现有应用程序，但问题是您想要依赖的行为是编译器当前失败的行为(即不是现有应用程序)。语言更新总是将非编译代码变成编译代码。例如，可以保证以下代码不会在 Java 7 中编译，但会在 Java 8 中编译:

static Runnable x = () -> System.out.println();

您的用例也不异常(exception)。

我对使用您的 withX 持谨慎态度的另一个原因方法是 F参数本身。通常， 上的泛型类型参数方法 (没有出现在返回类型中)存在以将签名的多个部分的类型绑定(bind)在一起。是说:

我不在乎什么 T是，但要确保无论我在哪里使用 T它是相同的类型。

从逻辑上讲，我们希望每个类型参数在方法签名中至少出现两次，否则“它什么都不做”。 F在您的 withX仅在签名中出现一次，这向我建议使用不符合语言此功能意图的类型参数。

替代实现

以稍微更“预期行为”的方式实现这一点的一种方法是拆分您的 with方法最多变成 2 个链:

public class Builder<T> {

    public final class With<R> {
        private final Function<T,R> method;

        private With(Function<T,R> method) {
            this.method = method;
        }

        public Builder<T> of(R value) {
            // TODO: Body of your old 'with' method goes here
            return Builder.this;
        }
    }

    public <R> With<R> with(Function<T,R> method) {
        return new With<>(method);
    }

}

然后可以按如下方式使用:

b.with(MyInterface::getLong).of(1L); // Compiles
b.with(MyInterface::getLong).of("Not a long"); // Compiler error

这不包括像 withX 这样的无关类型参数。确实。通过将方法分解为两个签名，从类型安全的角度来看，它还可以更好地表达您要执行的操作的意图:

第一个方法设置一个类( With )，该类定义基于方法引用的类型。

第二个方法( of )约束了 value 的类型与您之前设置的内容兼容。

该语言的 future 版本能够编译它的唯一方法是实现完整的鸭子类型，这似乎不太可能。

使整件事变得无关紧要的最后一点:我想 Mockito (尤其是它的 stub 功能)可能基本上已经完成了您尝试使用“类型安全通用构建器”实现的目标。也许你可以用它来代替？

完整的(ish)解释

我将通过 type inference procedure 工作两者都适用 with和 withX .这一段很长，慢慢来吧。尽管很长，但我仍然遗漏了很多细节。您可能希望引用规范以获取更多详细信息(点击链接)以说服自己我是对的(我很可能犯了错误)。

此外，为了稍微简化一些事情，我将使用更小的代码示例。主要区别在于它换出 Function为 Supplier ，因此可以使用的类型和参数较少。这是一个完整的片段，可以重现您描述的行为:

public class TypeInference {

    static long getLong() { return 1L; }

    static <R> void with(Supplier<R> supplier, R value) {}
    static <R, F extends Supplier<R>> void withX(F supplier, R value) {}

    public static void main(String[] args) {
        with(TypeInference::getLong, "Not a long");       // Compiles
        withX(TypeInference::getLong, "Also not a long"); // Does not compile
    }

}

让我们通过类型 applicability inference和 type inference依次为每个方法调用过程:
with
我们有:

with(TypeInference::getLong, "Not a long");

初始边界集 B0 是:

R <: Object

所有参数表达式为 pertinent to applicability .

因此，为 applicability inference 设置的初始约束, C, 是:

TypeInference::getLong兼容 Supplier<R>

"Not a long"兼容 R

此 reduces绑定(bind) B2 的集合:

R <: Object (来自 B0)

Long <: R (来自第一个约束)

String <: R (来自第二个约束)

由于这不包含边界“假”，并且(我假设) resolution的 R成功(给出 Serializable )，则调用适用。

所以，我们继续到 invocation type inference .

带有相关输入和输出变量的新约束集 C 是:

TypeInference::getLong兼容 Supplier<R>

输入变量:无

输出变量:R

这不包含输入和输出变量之间的相互依赖性，因此可以是 reduced一步完成，最终的边界集 B4 与 B2 相同。因此， resolution照样成功，编译器松了口气!
withX
我们有:

withX(TypeInference::getLong, "Also not a long");

初始边界集 B0 是:

R <: Object

F <: Supplier<R>

只有第二个参数表达式是 pertinent to applicability .第一个 ( TypeInference::getLong ) 不是，因为它满足以下条件:

If m is a generic method and the method invocation does not provide explicit type arguments, an explicitly typed lambda expression or an exact method reference expression for which the corresponding target type (as derived from the signature of m) is a type parameter of m.

因此，为 applicability inference 设置的初始约束, C, 是:

"Also not a long"兼容 R

此 reduces绑定(bind) B2 的集合:

R <: Object (来自 B0)

F <: Supplier<R> (来自 B0)

String <: R (来自约束)

同样，由于这不包含边界“false”，并且 resolution的 R成功(给出 String )，则调用适用。

Invocation type inference再一次……

这一次，带有相关输入和输出变量的新约束集 C 是:

TypeInference::getLong兼容 F

输入变量:F

输出变量:无

同样，我们在输入和输出变量之间没有相互依赖性。然而这一次，还有 是 一个输入变量( F )，所以我们必须 resolve尝试此之前 reduction .所以，我们从我们的边界集 B2 开始。

我们确定一个子集 V如下:

Given a set of inference variables to resolve, let V be the union of this set and all variables upon which the resolution of at least one variable in this set depends.

由 B2 中的第二个边界，F 的分辨率取决于 R ，所以 V := {F, R} .

我们选择 V 的一个子集根据规则:

let { α1, ..., αn } be a non-empty subset of uninstantiated variables in V such that i) for all i (1 ≤ i ≤ n), if αi depends on the resolution of a variable β, then either β has an instantiation or there is some j such that β = αj; and ii) there exists no non-empty proper subset of { α1, ..., αn } with this property.

V的唯一子集满足这个性质的是 {R} .

使用第三个界限( String <: R )我们实例化 R = String并将其合并到我们的绑定(bind)集中。 R现在解决了，第二个界限实际上变成了 F <: Supplier<String> .

使用(修改后的)第二个界限，我们实例化 F = Supplier<String> . F现在已解决。

现在， F解决了，我们可以继续 reduction ，使用新约束:

TypeInference::getLong兼容 Supplier<String>

...减少到 Long兼容 String

...减少到错误

...我们得到一个编译器错误!

关于“扩展示例”的附加说明

扩展示例 在问题中着眼于上述工作未直接涵盖的一些有趣案例:

其中值类型是方法返回类型的子类型 ( Integer <: Number )

函数接口(interface)在推断类型中是逆变的(即 Consumer 而不是 Supplier )

特别是，给定的调用中有 3 个突出显示可能暗示与解释中描述的“不同”的编译器行为:

t.lettBe(t::setNumber, "NaN"); // Does not compile :-)

t.letBeX(t::getNumber, 2); // !!! Does not compile  :-(
t.lettBeX(t::setNumber, 2); // Compiles :-)

这 3 个中的第二个将经历与 withX 完全相同的推理过程。以上(只需将 Long 替换为 Number 并将 String 替换为 Integer )。这说明了为什么您不应该在类设计中依赖这种失败的类型推断行为的另一个原因，因为在此处编译失败可能不是理想的行为。

对于其他 2 个(以及您希望通过的任何其他涉及 Consumer 的调用)，如果您通过为上述方法之一(即 with)制定的类型推断程序进行工作，则行为应该很明显。对于第一个， withX 对于第三个)。您只需要注意一个小变化:

第一个参数( t::setNumber 与 Consumer<R> 兼容)的约束将 reduce至 R <: Number而不是 Number <: R就像 Supplier<R> 一样.这在有关减少的链接文档中有所描述。

我将其作为练习让读者仔细完成上述过程之一，并配备了这一额外知识，以向自己展示为什么特定调用编译或不编译。