Community
Participate
Working Groups
Build ID: generics primitive autoboxing Steps To Reproduce: In the following code (class Foo), both m1 and m2 are invalid methods and should be equivalent due to autoboxing. Javac reports both as invalid, however eclipse's compiler incorrectly accepts the method m1. If the method m2 is removed, the class may be compiled (by eclipse's compiler) and run normally. public class Foo { public <T extends Integer> T m1() { return 35; } public <T extends Integer> T m2() { return new Integer(35); } public static void main(String[] args) { System.out.println(m1()); } } More information: Originally reported in http://www.guj.com.br/posts/list/118023.java
Test case: [public class X { public <T extends Integer> T m1() { return 35; } public <T extends Integer> T m2() { return new Integer(35); } public static void main(String[] args) { System.out.println(new X().m1()); } }] javac 1.5, 1.6 and 1.7 are properly rejecting the code. javac 1.6: X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors javac 1.7 (b44): X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors javac 1.5: X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors
Created attachment 125658 [details] Proposed patch and testcase
Released fix and tests for 3.5M6
I think there is more than the return statement to fix. e.g. public class X<T extends Integer> { T foo(T t) { t = 5; // we should complain here too foo(6); // we do reject it ok already (why?) return t; } } Also I am not convinced this is the right fix. I suspect we have erasure conversion fooling us here... Reopening
Looking deeper, I think the fix is reasonable. However, there are more situations to fix in the same way, see test case below: field decl, local decl, assignment (the rest seems fine since cannot cause grief) public class X<T extends Integer> { T field = 12; T foo(T t) { t = 5; foo(6); T t1 = t == null ? t : 8; T t2 = 9; T[] t3 = { 10 }; perform(10); return 7; } T bar(T t) { int i = 0; t = i; foo(i); T t1 = t == null ? t : i; T t2 = i; T[] t3 = { i }; perform(i); return i; } void baz(T t) { int i = t; i+= t; } void perform(T... t) {} }
I would also like a 3.4 version of the fix, given it feels an obvious case (for 3.4.x)
Created attachment 125920 [details] Proposed patch and testcase
Created attachment 125935 [details] Proposed patch and testcase for 3.4.x
Released fix and test for 3.5M6
Released into 3.4.x branch (post 3.4.2)
Verified for 3.5M6 using I20090309-0100.
