-
Bug
-
Resolution: Duplicate
-
P5
-
None
-
5.0
-
generic
-
generic
Good question. At the very least javac and the spec don't agree. I think the compiler is doing what I intended, but I can't see any harm in the specified behavior. Let's call it a javac bug.
On 12/13/06, ... wrote:
This case is rejected as ambiguous by javac 1.5:
class A {
void f(int ... x) {}
void f(double ... x) {}
void g() {
f(0);
}
}
We accept it, and my reading of the 15.12.2.5 rules suggest we're
doing the
right thing, because the int... is more specific than the double...
method.
javac bug, or am I misunderstanding the rules?
(If I take out the "..." on both, the int method is selected, of course,
by both javac and our front end.)
On 12/13/06, ... wrote:
This case is rejected as ambiguous by javac 1.5:
class A {
void f(int ... x) {}
void f(double ... x) {}
void g() {
f(0);
}
}
We accept it, and my reading of the 15.12.2.5 rules suggest we're
doing the
right thing, because the int... is more specific than the double...
method.
javac bug, or am I misunderstanding the rules?
(If I take out the "..." on both, the int method is selected, of course,
by both javac and our front end.)
- duplicates
-
JDK-6199075 Unambiguous varargs method calls flagged as ambiguous
- Closed