-
Bug
-
Resolution: Fixed
-
P3
-
5.0, 6
-
b05
-
x86
-
windows_xp
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2145975 | 6u10 | Kumar Srinivasan | P3 | Resolved | Fixed | b13 |
JDK-2152444 | OpenJDK6 | Jonathan Gibbons | P3 | Closed | Not an Issue |
FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
The overload resolution mechansm for javac 1.5 seems not to cope with the pattern used in the attached code
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
compile the test application
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
should compile and resolve the overload
ACTUAL -
javac failed, with error deatiled below
ERROR MESSAGES/STACK TRACES THAT OCCUR :
reference to addAll is ambiguous, both method addAll(java.util.Collection<? extends E>) in java.util.Collection<? super A> and method addAll(java.util.Collection<? extends E>) in java.util.List<? super A> match
l.addAll(getRelated(b));
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.Collections;
import java.util.List;
public class Test<A,B> {
private List<A> getRelated(B b) {
return Collections.emptyList();
}
public <L extends List<? super A>> L addOrCreate(B b,L l) {
l.addAll(getRelated(b));
return l;
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
dont use this pattern, chnage to interfaces, and developed code.
Simplified testcase submitted by another customer:
import java.util.Set;
public class GenericCaptureAddingTest {
public void test(Set<? super Number> numbers, Set<Number> someNumbers) {
numbers.addAll(someNumbers);
}
}
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
The overload resolution mechansm for javac 1.5 seems not to cope with the pattern used in the attached code
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
compile the test application
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
should compile and resolve the overload
ACTUAL -
javac failed, with error deatiled below
ERROR MESSAGES/STACK TRACES THAT OCCUR :
reference to addAll is ambiguous, both method addAll(java.util.Collection<? extends E>) in java.util.Collection<? super A> and method addAll(java.util.Collection<? extends E>) in java.util.List<? super A> match
l.addAll(getRelated(b));
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.Collections;
import java.util.List;
public class Test<A,B> {
private List<A> getRelated(B b) {
return Collections.emptyList();
}
public <L extends List<? super A>> L addOrCreate(B b,L l) {
l.addAll(getRelated(b));
return l;
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
dont use this pattern, chnage to interfaces, and developed code.
Simplified testcase submitted by another customer:
import java.util.Set;
public class GenericCaptureAddingTest {
public void test(Set<? super Number> numbers, Set<Number> someNumbers) {
numbers.addAll(someNumbers);
}
}
- backported by
-
JDK-2145975 javac incorrectly generates "reference to <xx> is ambiguous"
- Resolved
-
JDK-2152444 javac incorrectly generates "reference to <xx> is ambiguous"
- Closed
- duplicates
-
JDK-6507334 Generic compiler signals ambiguous method declaration although signatures already differ
- Closed
- relates to
-
JDK-6365166 javac (generic) unable to resolve methods
- Closed