-
Bug
-
Resolution: Fixed
-
P4
-
8
For exact method references, 18.5.4 produces these constraints:
"For all j (1 ≤ j ≤ k), ‹Uj = Vj›"
For explicitly typed lambda expressions, the same should occur. (This was overlooked because it's unnecessary in 15.12.2.5: if a lambda is compatible with two function types, then in the absence of inference variables, the parameter types of all three must be the same.)
JDK-8034223 already addresses this, and adds a test:
interface UnaryOp<T> { T apply(T arg); }
interface IntegerToNumber { Number apply(Integer arg); }
<T> void m(UnaryOp<T> f) {}
void m(IntegerToNumber f) {}
void test() {
m((Integer i) -> i);
}
"For all j (1 ≤ j ≤ k), ‹Uj = Vj›"
For explicitly typed lambda expressions, the same should occur. (This was overlooked because it's unnecessary in 15.12.2.5: if a lambda is compatible with two function types, then in the absence of inference variables, the parameter types of all three must be the same.)
interface UnaryOp<T> { T apply(T arg); }
interface IntegerToNumber { Number apply(Integer arg); }
<T> void m(UnaryOp<T> f) {}
void m(IntegerToNumber f) {}
void test() {
m((Integer i) -> i);
}
- relates to
-
JDK-8034223 Most-specific should not have any special treatment for boxed vs. unboxed types
- Closed