作者tkcn (小安)
看板java
標題Re: [問題] Wrapping/Widening + Var-args
時間Wed Sep 8 22:20:10 2010
※ 引述《bennylu (減肥)》之銘言：
: How about this example
: method(5);
: ..
: void method(int... i) {System.out.print("int...");}
: void method(long... i) {System.out.print("long...");}
: 如果沒會錯意, 那3個步驟只能告訴我哪些method是符合資格的,
: 但並沒有提到當有多個候選人時該如何作選擇, 所以也不會提到ambiguous問題,
: 下面這篇文章和我有一樣的問題
: http://java.itags.org/java-certification/337/
結論先說在前頭，
我的看法跟你連結裡 jesperyoung 所回覆的相同，
這確實是一個 compiler 的 bug。
===
在 JLS 15.12 Method Invocation Expressions 中有詳細的定義:
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12
在 15.12.2 提到:
If several applicable methods have been identified during one of the three
phases of applicability testing, then the most specific one is chosen.
applicable method 的定義則是:
A method is applicable if it is either applicable by subtyping (§15.12.2.2),
applicable by method invocation conversion (§15.12.2.3),
or it is an applicable variable arity method (§15.12.2.4).
(剛好對應三個階段。)
註: JLS 對這三個階段的定義比較詳細，
我先前貼的直接將 generics method 忽略掉了。
完整定義請參考 15.12.2.2 ~ 15.12.2.4
在做 method resolution 時，會依序測試那三個階段，
如果在任何一個階段中，
只有一個 the most specific method，就可以選定它。
如果有多個 the most specific method，便是 ambiguous。
若一個都沒有，則繼續下一個階段。
剩下最後一個問題是，如何找出 most specific method?
當有兩個 method m1, m2 皆為 applicable 時，
並且 m1 的每一個 parameter 都是 m2 parameter 的 subtype 時，
我們稱 m1 is more specific than m2。
註: 上面為了方便說明，我忽略了 generics 和 varargs，
正確定義請參考 15.12.2.5
讓我直接舉兩個例子:
void foo(int a, long b){} // m1
void foo(long a, int b){} // m2
當我呼叫 foo 並傳入兩個 int 時，如 foo(0,1)，
m1, m2 之間並不存在 more specific 關係，
因此 m1, m2 都是 most specific method，造成 ambiguous。
第二個例子:
void foo(float a, long b){} // m1
void foo(long a, int b){} // m2
在這個例子中，因為 m2 的兩個參數都可以 implicitly casting 成 m1 的參數，
因此 m2 is more specific method than m1，
所以 resolution 的結果會是選擇 m2。
註: 對於 primitive type 來說，subtype 的定義為:
"被箭頭指向的 type" 是 "指向它人的 type" 的 subtype，
即 int 是 byte, short, char 的 subtype。
詳細可參考 4.10.1。
8-bits 16-bits 32-bits 64-bits
-----------------------------------------------
byte ──→ short ─┬→ int ──→ long
(signed) │ ┌────┘
char ─┘ ↓
(unsigned) float ─→ double
結論就是，根據 JLS 的定義，
void method(int... i) {System.out.print("int...");}
void method(long... i) {System.out.print("long...");}
method(5) 應該會執行參數為 int... 的 method，
但 compiler 卻沒有這樣做，並且認為這是 ambiguous。
而因為這個 bug 的 priority 是 Vary Low，
所以拖了近六年至今還沒被處理掉....XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.115.134.17
※ 編輯: tkcn 來自: 59.115.134.17 (09/08 22:20)
1F：→ ogamenewbie:把 int 換成 Integer 也一樣嗎? 09/08 22:31
2F：→ ogamenewbie:歐, 沒事, 我以為原po還是 Integer... vs long... 09/08 22:47
3F：→ tkcn:如果是最後一個例子，換成 Integer 也一樣不正確 09/08 22:49
4F：→ ogamenewbie:不正確的意思是 compiler bug 還是 compiler error? 09/08 22:51
5F：→ tkcn:compiler 顯示 error，但定義是不會才對，所以也是 bug 09/08 22:55
6F：→ ogamenewbie:可是照定義不就是會走到 pass 3 然後 amb 掉嗎? 09/08 23:17
7F：→ ogamenewbie:對不起, 我是 int -> Integer, ... 依舊保留的意思 09/08 23:18
8F：→ tkcn:看不是很懂 @@ 09/08 23:21
9F：→ tkcn:好像看懂了,到phase 3時Integer還是比long more specific, 09/08 23:38
10F：→ tkcn:所以根據定義，會選Interger那method去執行 (但目前不是) 09/08 23:43
11F：→ ogamenewbie:請問一下在 JLS 的 pass 中是哪邊有關於 Integer... 09/09 01:02
12F：→ ogamenewbie:要 boxing 且 long 要作型轉才會在 pass 3 的情況下. 09/09 01:06
13F：→ ogamenewbie:boxing 會比型轉 more specific 的說明阿? @_@ 09/09 01:07
前面推文的時後完全忘記我可以回來修文章 Orz
我要說的範圍都在 15.12.2.5 之內，
Integer 比 long more specific 這點應該毫無疑問(非 varargs 情況下)，
這個部份在 phase 2 就會完成，根據 15.12.2.3:
For 1<=i<=n, the type of ei, Ai, can be converted by
method invocation conversion (§5.3) to Si.
節錄 5.3:
Method invocation contexts allow the use of one of the following:
a boxing conversion (§5.1.7) optionally followed by widening reference
conversion
an unboxing conversion (§5.1.8) optionally followed by a widening
primitive conversion.
而根據 phase 3 定義，並沒有任何違反上述規則的條件。
※ 編輯: tkcn 來自: 140.122.183.199 (09/09 09:20)
14F：推 ogamenewbie:不要漏掉...啊. (雖然我自己一直在漏掉 orz 09/09 11:52
15F：→ tkcn:我說 phase 3 就是指加上 varargs 了，定義沒衝突 09/09 11:54