-
Bug
-
Resolution: Fixed
-
P3
-
8
-
b14
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8045169 | 8u25 | Dan Smith | P3 | Resolved | Fixed | b01 |
JDK-8034993 | 8u20 | Dan Smith | P3 | Resolved | Fixed | b15 |
JDK-8052608 | emb-8u26 | Dan Smith | P3 | Resolved | Fixed | b17 |
static void m(Object dummy, int arg) { System.out.println("int"); }
static void m(Object dummy, Integer arg) { System.out.println("Integer"); }
public static void main(String... args) {
m(0, 23);
m(0, Integer.valueOf(23));
}
(The first invocation prints "int"; the second prints "Integer".)
This was an experimental feature in Lambda that we ultimately agreed to undo for 8. The return expressions of _lambdas_ should continue to get special treatment, but a top-level argument should not. The only mechanism for treating one parameter type as better than another in this case should be subtyping.
- backported by
-
JDK-8034993 Most-specific should not have any special treatment for boxed vs. unboxed types
-
- Resolved
-
-
JDK-8045169 Most-specific should not have any special treatment for boxed vs. unboxed types
-
- Resolved
-
-
JDK-8052608 Most-specific should not have any special treatment for boxed vs. unboxed types
-
- Resolved
-
- relates to
-
JDK-8037789 Surprising more-specific results for lambda bodies with no return expressions
-
- Closed
-
-
JDK-8042344 18.5.4: Need bounds ensuring parameter types are the same
-
- Closed
-
-
JDK-8132544 Compiler method binding error on overloaded method when varargs is present
-
- Closed
-