Community
Participate
Working Groups
3.6M3 While working on bug#277643 I noticed that we actually compute the return type of generic methods incorrectly in some situations. For example in org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1325() (reproduced below) public class X<E> { <T,U> U foo(X<T> xt) { return null; } void bar(X x) { X<String> xs2 = foo(x); } } if you debug the compiler and break at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(BlockScope) and run until just after the line: this.binding = this.receiver.isImplicitThis() ? scope.getImplicitMethod(this.selector, argumentTypes, this) : scope.getMethod(this.actualReceiverType, this.selector, argumentTypes, this); and then inspect the value of the binding computed, you will get X<java.lang.String> foo(X<java.lang.Object>) This is completely bogus and it should be java.lang.Object instead. Similar problems exist in org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1406() org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1407() org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1434()
Some background: Prior to the fix for bug 258798, we would compile the code below without any complaints: import java.util.*; public class GenericTest { public static void test() { Set testList = GenericTest.method1(new Class[] { ArrayList.class }); } public static <I> I method1(Class<List>[] params) { return null; } } With the proposed fix for bug 277643, this behavior reappears. But that is incorrect and hence this bug. javac (7b75) complains: [...] GenericTest.java:4: incompatible types Set testList = GenericTest.method1(new Class[] { ArrayList.class }); ^ required: Set found: Object 1 error 2 warnings Before the fix for bug 277643 and after the fix for bug 258798, we would reject this code with the same message as javac, but that was entirely by luck.
(In reply to comment #0) > if you debug the compiler and break at > org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(BlockScope) > and run until just after the line: > this.binding = this.receiver.isImplicitThis() > ? scope.getImplicitMethod(this.selector, argumentTypes, this) > : scope.getMethod(this.actualReceiverType, this.selector, > argumentTypes, this); > and then inspect the value of the binding computed, you will get > X<java.lang.String> foo(X<java.lang.Object>) > This is completely bogus and it should be java.lang.Object instead. This needs more study. See JLS 15.12.2.8 Inferring Unresolved Type Arguments. Javac has/had many defects here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6650759 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6640435 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721089 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6638712 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6721146
I am closing this internally reported defect as WONTFIX. This seems to fall in the gray area of the JLS and there are also many open defects in javac in this space. So until and unless there is a real and significant customer impact, it is too risky to change eclipse behavior here.
Verified for 3.7M2
