Details
-
Type:
Bug
-
Status: Closed
-
Priority:
P4
-
Resolution: Fixed
-
Affects Version/s: 8
-
Fix Version/s: 8u40
-
Component/s: specification
-
Labels:
-
Subcomponent:
Description
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);
}
Attachments
Issue Links
- relates to
-
JDK-8034223 Most-specific should not have any special treatment for boxed vs. unboxed types
-
- Closed
-