-
Bug
-
Resolution: Fixed
-
P4
-
8
-
b123
-
Verified
When comparing two functional interface types during the most-specific test, JLS 8 15.12.2.5 says the first type should be captured. javac fails to do this, producing unsound results.
void m2(Predicate<? extends Integer>)
void m2(Function<? super Integer, Boolean>)
m2(x -> true);
// expected: ambiguous; actual: Predicate treated as more specific
However, the JLS 8 spec produces some unfortunate ambiguities.JDK-8143576 addresses this by improving the spec's handling of capture variables in parameter types.
void m1(Predicate<? super Integer>)
void m1(Function<? super Integer, Boolean>)
m1(x -> true);
// JLS 8 specified: ambiguous; expected/actual: Predicate treated as more specific
At the same time, we don't want to allow full contravariance of parameter types:
void m1(Predicate<? super Number>)
void m1(Function<? super Integer, Boolean>)
m1(x -> true);
// expected/actual: ambiguous
void m2(Predicate<? extends Integer>)
void m2(Function<? super Integer, Boolean>)
m2(x -> true);
// expected: ambiguous; actual: Predicate treated as more specific
However, the JLS 8 spec produces some unfortunate ambiguities.
void m1(Predicate<? super Integer>)
void m1(Function<? super Integer, Boolean>)
m1(x -> true);
// JLS 8 specified: ambiguous; expected/actual: Predicate treated as more specific
At the same time, we don't want to allow full contravariance of parameter types:
void m1(Predicate<? super Number>)
void m1(Function<? super Integer, Boolean>)
m1(x -> true);
// expected/actual: ambiguous
- relates to
-
JDK-8143852 Implement type variable renaming for functional interface most specific test
-
- Closed
-
-
JDK-8143576 15.12.2.5: Refine parameter equality constraint for functional most-specific test
-
- Closed
-