为什么这个 Java 方法调用被认为是模棱两可的？答案

【问题标题】：Why is this Java method call considered ambiguous?为什么这个 Java 方法调用被认为是模棱两可的？
【发布时间】：2019-11-28 18:55:09
【问题描述】：

我遇到了一条奇怪的错误消息，我认为它可能不正确。考虑以下代码：

public class Overloaded {
    public interface Supplier {
        int get();
    }

    public interface Processor {
        String process(String s);
    }

    public static void load(Supplier s) {}
    public static void load(Processor p) {}

    public static int genuinelyAmbiguous() { return 4; }
    public static String genuinelyAmbiguous(String s) { return "string"; }

    public static int notAmbiguous() { return 4; }
    public static String notAmbiguous(int x, int y) { return "string"; }

    public static int strangelyAmbiguous() { return 4; }
    public static String strangelyAmbiguous(int x) { return "string"; }
}

如果我有一个看起来像这样的方法：

// Exhibit A
public static void exhibitA() {
    // Genuinely ambiguous: either choice is correct
    load(Overloaded::genuinelyAmbiguous); // <-- ERROR
    Supplier s1 = Overloaded::genuinelyAmbiguous;
    Processor p1 = Overloaded::genuinelyAmbiguous; 
}

我们得到的错误是完全有道理的； load() 的参数可以分配给任何一个，所以我们得到一个错误，指出方法调用不明确。

相反，如果我有一个看起来像这样的方法：

// Exhibit B
public static void exhibitB() {
    // Correctly infers the right overloaded method
    load(Overloaded::notAmbiguous);
    Supplier s2 = Overloaded::notAmbiguous;
    Processor p2 = Overloaded::notAmbiguous; // <-- ERROR
}

对load() 的调用很好，正如预期的那样，我无法将方法引用分配给Supplier 和Processor，因为它没有歧义：Overloaded::notAmbiguous 不能分配给p2。

现在是奇怪的。如果我有这样的方法：

// Exhibit C
public static void exhibitC() {
    // Complains that the reference is ambiguous
    load(Overloaded::strangelyAmbiguous); // <-- ERROR
    Supplier s3 = Overloaded::strangelyAmbiguous;
    Processor p3 = Overloaded::strangelyAmbiguous; // <-- ERROR
}

编译器抱怨对load() 的调用不明确（error: reference to load is ambiguous），但与图表A 不同的是，我不能将方法引用分配给Supplier 和Processor。如果它真的模棱两可，我觉得我应该能够将 s3 和 p3 分配给这两种重载参数类型，就像在图表 A 中一样，但我在 p3 上收到一个错误，指出 error: incompatible types: invalid method reference。 Exhibit C 中的第二个错误是有道理的，Overloaded::strangelyAmbiguous 不能分配给 Processor，但如果它不可分配，为什么它仍然被认为是模棱两可的？

在确定选择哪个重载版本时，方法引用推断似乎只查看 FunctionalInterface 的数量。在变量赋值中，检查arity 和类型的参数，导致重载方法和变量赋值之间存在这种差异。

在我看来，这就像一个错误。如果不是，那么至少错误消息是不正确的，因为当两个选项之间只有一个是正确的时，可以说没有歧义。

【问题讨论】：

我可以复制，但是请您删除“exhibit A”和“exhibit B”吗？我不认为它们并没有真正增加对问题的理解。展览 C 本身就很好。
请记住，人类必须维护此代码。即使编译器可以解决，我更喜欢 loadProcessor 和 loadSupplier 这样的名称，所以我不必考虑它。
@markspace 请记住，作为人类，我们喜欢了解它的实际工作原理
@ArnaudClaudel 是的，我知道，这就是为什么它是评论，而不是答案。可以问，但这个问题主要是学术性的。我希望没有人以这种方式编写生产代码。

标签： java overloading method-reference functional-interface arity

【解决方案1】：

您的问题与this one 非常相似。

简短的回答是：

Overloaded::genuinelyAmbiguous;
Overloaded::notAmbiguous;
Overloaded::strangelyAmbiguous;

所有这些方法引用都不准确（它们有多个重载）。因此，根据JLS §15.12.2.2.，它们在重载解决期间从适用性检查中被跳过，从而导致歧义。

这种情况下，需要明确指定类型，例如：

load((Processor) Overloaded::genuinelyAmbiguous);
load(( Supplier) Overloaded::strangelyAmbiguous);

【讨论】：

【解决方案2】：

方法引用和重载，只是……不要。从理论上讲，您是正确的 - 这应该对于编译器来说相当容易推断，但我们不要混淆人类和编译器。

编译器看到对load 的调用并说：“嘿，我需要调用那个方法。很酷，可以吗？好吧，有两个。当然，让我们匹配参数”。那么参数是对重载方法的方法引用。所以编译器在这里变得非常困惑，它基本上说：“如果我能告诉你指向哪个方法引用，我可以打电话给load，但是，如果我能分辨出哪个@987654323 @你想调用的方法，我可以推断出正确的strangelyAmbiguous"，因此它只是绕圈子，追逐它的故事。这是编译器“头脑”中做出的决定是我能想到的最简单的解释方式。这带来了一个很好的坏习惯 - 方法重载和方法引用是一个坏主意。

但是，您可能会说 - ARITY！参数的数量是编译器在决定这是否是重载时（可能）做的第一件事，这正是你的观点：

Processor p = Overloaded::strangelyAmbiguous;

对于这种简单的情况，编译器确实可以推断出正确的方法，我的意思是我们人类可以，对于编译器来说应该是不费吹灰之力的。这里的问题是，这是一个只有 2 个方法的简单案例，那么 100*100 个选项呢？设计者必须要么允许某些东西（比如说最多 5*5 并允许这样的分辨率）或完全禁止 - 我猜你知道他们采取的路径。如果您使用 lambda，这应该很明显为什么会起作用 - arity 是 right 那里，明确的。

关于错误消息，这不是什么新鲜事，如果你对 lambda 和方法引用玩得够多，你会开始讨厌错误消息：“一个非静态方法不能从一个静态上下文”，而 字面上 与此无关。 IIRC 这些错误消息已从 java-8 及更高版本改进，你永远不知道此错误消息是否也会在 java-15 中得到改进，比方说。

【讨论】：