小编典典
首先,让我们考虑一个没有三进制条件并且不能在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