Community
Participate
Working Groups
Such code : XXList<Class> statements = null; public List<Class> compute() { statements = new ArrayList<Class>(); return statements; } Don't compile, but with Eclipse 3.3 you can resolve the binding for "ArrayList<Class>". In 3.4 it's no more possible.
How to reproduce : Paste that code : package tests.generics; import java.util.ArrayList; import java.util.List; public class CapitalizeTest { XXList<Class> statements = null; public List<Class> compute() { statements = new ArrayList<Class>(); return statements; } } (the code does not compile but it's what I want) Open ASTViews and select "ArrayList<Class>". Look for the binding value of the "ParametrizedType". With 3.3.1.1 you have a value and with 3.4 you have "null".
Did you try to set the binding recovery ?
3.3 did leak some "recovered" type bindings by mistake when binding recovery wasn't activated. This got addressed during 3.4, along with providing much more resilience near missing types. So in 3.4 you should not see recovered bindings, when recovery is off; and when it is on, you should find many more bindings available.
Hello, Ok, set recover binding to true solve that case. But in a case like this : public class AbstractClass { XXList<Class> statements = null; } public class CapitalizeTest extends AbstractClass { public List<Class> compute() { statements = new ArrayList<Class>(); return statements; } } The binding for "ArrayList<Class>" is not resolved ... (of course my use case is more complexe : a plugin that apply many ast transformation on CompilationUnit)
Do you have the import for java.util.ArrayList in your last example as you do in the first one? or it is not there on purpose ?
The import for java.util.ArrayList is present in my sample. I just forget to write it.
The problem doesn't directly come from the DOM support. The compiler doesn't even try to resolve the right hand side of the assignment as the resolution of the left hand side (statements) fails with an AbortMethod exception through an invalid type error report. The id of the type is not known so it goes into the "needImplementation(...)" call that aborts the type resolution. Updating title accordingly. Once the compiler can fully resolve the assignment, the DOM binding should be able to reflect this.
Looking at the issue, I don't see how setting the binding recovery fixed the test case in comment 1. I think I have a fix for this one.
Created attachment 108236 [details] Proposed fix + regression tests for HEAD This might deserve a backport to 3.4.1.
The change looks straight forward to me.
*** Bug 241399 has been marked as a duplicate of this bug. ***
Released for 3.5M1. Philippe, this should be a candidate for 3.4.1.
Added regression tests: org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0316 org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0317
Added regression test org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test1367
Ok for 3.4.1.
Backported to 3.4 maintenance stream. Regression tests: org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0315 org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0316 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test1367
Verified for 3.5M1 using I20080805-1307
Verified for 3.4.1 using M20080827-2000
