重载 装箱 java,Java 8三元条件和未装箱原语的方法重载歧义

小编典典

首先，让我们考虑一个没有三进制条件并且不能在Java HotSpot VM(版本1.8.0_25-b17)上编译的简化版本：

public class Test {

void f(Object o1, int i) {}

void f(Object o1, Object o2) {}

void test() {

double d = 1.0;

int i = 1;

f(d, i); // ERROR! Ambiguous

}

}

编译器错误是：

Error:(12, 9) java: reference to f is ambiguous

both method f(java.lang.Object,int) in test.Test and method f(java.lang.Object,java.lang.Object) in test.Test match

如果通过严格调用(§15.12.2.2)，松散调用(§15.12.2.3)或可变arity调用(§15.12.2.4)之一应用方法，则该方法适用。

当方法调用不涉及装箱或拆箱时，则应用严格调用。当方法调用涉及装箱或拆箱时，则应用松散调用。

确定适用方法分为三个阶段。

第一阶段(第15.12.2.2节)执行重载解析，而不允许装箱或拆箱转换，也不允许使用可变arity方法调用。

如果在此阶段未找到适用的方法，则处理将继续进行到第二阶段。

第二阶段(第15.12.2.3节)在允许装箱和拆箱的同时执行重载解析，但仍排除使用可变arity方法调用。

如果在此阶段未找到适用的方法，则处理将继续进行到第三阶段。

第三阶段(第15.12.2.4节)允许将重载与可变arity方法，装箱和拆箱相结合。

就我们而言，没有严格调用可应用的方法。两种方法都适用于松散调用，因为必须对double值进行装箱。

如果多个成员方法既可访问又可应用于方法调用，则必须选择一个成员方法来为运行时方法分派提供描述符。Java编程语言使用选择最具体方法的规则。

然后：

如果满足以下任一条件，则使用参数表达式e1，…，ek进行调用时，一个适用的方法m1比另一适用的方法m2更具体：

m2是通用的，并且对于第18.5.4节，对于参数表达式e1，…，ek推断m1比m2更具体。

2.

m2不是通用的，并且m1和m2可通过严格调用或宽松调用来应用，并且m1具有形式参数类型S1，…，Sn，而m2具有形式参数类型T1，…，Tn，则Si类型更多。对于所有i(1≤i≤n，n

= k)，自变量ei比Ti特定。

3.

m2不是通用的，并且m1和m2可通过可变arity调用来应用，并且其中m1的前k个可变arity参数类型为S1，…，Sk，而m2的前k个可变arity参数类型为T1，…。对于所有i(1≤i≤k)，自变量ei的类型Si比Ti更具体。另外，如果m2具有k

+ 1个参数，则m1个第k + 1个可变稀疏参数类型是m2个第k + 1个可变稀疏参数类型的子类型。

以上条件是一种方法可能比另一种方法更具体的唯一情况。

如果S

看起来第二个条件与此情况相匹配，但实际上并非如此，因为 int 不是Object的子类型： int

不是真的。但是，如果我们在f方法签名中将Int替换为Integer，则此条件将匹配。请注意，由于 Object

，因此方法中的第一个参数与此条件匹配。

根据$

4.10，在原始类型和类/接口类型之间没有定义子类型/超类型关系。因此，例如

int 不是 Object 的子类型。因此， int 不比 Object 更具体。

由于这两种方法之间没有 更多特定的方法，

因此也就没有

严格的更加特定的方法 ，也没有 最特定的 方法(JLS在同一段落JLS

15.12.2.5选择

最特定的 方法中给出了这些术语的定义)。因此，这两种方法都具有 最大的针对性 。

在这种情况下，JLS提供了两个选项：

如果所有最大特定方法都具有等效的签名(第8.4.2节)…

这不是我们的情况，因此

否则，方法调用将是不明确的，并且会发生编译时错误。

根据JLS，我们这种情况下的编译时错误看起来是有效的。

如果将方法参数类型从int更改为Integer，会发生什么？

在这种情况下，这两种方法仍然可以通过松散调用来应用。但是，由于Integer

如果在此行中将double更改为Double，将会发生什么：double d = 1.0 ;？

在这种情况下，严格调用有一种适用的方法：调用此方法不需要装箱或拆箱：f(Object o1，int

i)。对于另一种方法，您需要对int值进行装箱，以便通过松散调用将其应用。编译器可以选择通过严格调用而适用的方法，因此不会引发编译器错误。

正如Marco13在他的评论中指出的那样，本文讨论了类似的情况。为什么这种方法重载是模棱两可的？

如答案中所述，在Java 7和Java 8之间存在一些与方法调用机制相关的重大更改。这解释了为什么代码在Java 7中而不在Java 8中进行编译。

有趣的来了！

让我们添加一个三元条件运算符：

public class Test {

void f(Object o1, int i) {

System.out.println("1");

}

void f(Object o1, Object o2) {

System.out.println("2");

}

void test(boolean b) {

String s = "string";

double d = 1.0;

int i = 1;

f(b ? s : d, i); // ERROR! Ambiguous

}

public static void main(String[] args) {

new Test().test(true);

}

}

编译器抱怨方法调用不明确。该JLS

15.12.2没有规定执行的方法调用时与三元条件运算符的任何特殊规则。

但是，有JLS

15.25条件运算符吗？：和JLS

15.25.3。参考条件表达式。前一个将条件表达式分为3个子类别：布尔，数字和引用条件表达式。条件表达式的第二个和第三个操作数的类型分别为String和double。根据JLS，我们的条件表达式是参考条件表达式。

然后根据JLS

15.25.3。引用条件表达式我们的条件表达式是一个多引用条件表达式，因为它出现在调用上下文中。因此，我们的多条件表达式的类型是Object(调用上下文中的目标类型)。从这里开始，我们可以继续执行步骤，就好像第一个参数是Object一样，在这种情况下，编译器应选择int作为第二个参数的方法(并且不会引发编译器错误)。

棘手的部分是来自JLS的注释：

其第二和第三操作数表达式类似地出现在与目标类型T相同的上下文中。

由此我们可以假设(名称中的“

poly”也暗示了这一点)在方法调用的上下文中，应将两个操作数独立考虑。这意味着，当编译器必须决定是否需要对此类参数进行装箱操作时，它应查看每个操作数，并查看是否可能需要装箱。对于我们的特定情况，String不需要装箱，而double则需要装箱。因此，编译器决定对于两个重载方法，它都应该是一个松散的方法调用。进一步的步骤与使用三进制值而不是三进制条件表达式的情况相同。

从上面的解释中可以看出，当应用于重载方法时，JLS本身在与条件表达式有关的部分中是含糊不清的，因此我们必须做出一些假设。

有趣的是，我的IDE(IntelliJ

IDEA)不会将最后一种情况(带有三元条件表达式)检测为编译器错误。它根据JDK的java编译器检测到的所有其他情况。这意味着JDK

Java编译器或内部IDE解析器都有错误。

2020-10-20