Community
Participate
Working Groups
Build ID: I20070525-1350 Steps To Reproduce: --- pkg1/Foo.java --- package pkg1; public class Foo { public @interface Moo { Class<?> value(); } @Moo(Bar.Baz.class) public static class Bar { public static class Baz { } } } ------ --- pkg2/Bar.java --- package pkg2; public class Bar { } ------ Create a new Java Project and add those two source files to it. Perform Organize Imports on Foo. The "Bar" in the annotation will be highlighted and a disambiguation dialog will appear containing "pkg1.Foo.Bar" and "pkg2.Bar". Choosing "pkg1.Foo.Bar" produces no change to the file. Performing Organize Imports again repeats the pattern.
Moving to JDT/UI
The reason why organize prompts for a type is that the type binding for 'Bar' is marked as 'recovered'. As this CU is compiling, this seems to be wrong. When looking at the CU in the ASTView, another problem shows up: The Java element returned by the binding (binding.getJavaElement) returns a CU with 'null' as parent. Should be a IType (or null). CU's should never return 'null' as parent, but always a package. I marked this bug as 3.3.1, but jdt.core can decide if they prefer 3.4.
Reproduced. I am investigating.
(In reply to comment #2) > When looking at the CU in the ASTView, another problem shows up: The Java > element returned by the binding (binding.getJavaElement) returns a CU with > 'null' as parent. > Should be a IType (or null). CU's should never return 'null' as parent, but > always a package. I believe that the java element for a recovered type binding should always be null. Returning a fake compilation unit looks boggus. I fixed the initial problem which also fix the java element.
If we don't set null for the compilation unit parent, we need to provide a package fragment and therefore we need to provide a package fragment root. I opened bug 201104 to track this issue.
Jérôme, Candidate for 3.3.1? Potentially all qualified name inside annotation on a type declaration cannot properly get a binding. Released for 3.4M2. Regression test added org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0282
I agree that null is much better answer here. getJavaElement() for a ITypeBinding should always be an IType or null. In our code we assume that getParent() of a ICompilationUnit is never null. This has been true since 1.0 I believe although it hasn't been explicitly stated. Only IJavaModel.getParent returns null.
Olivier, please attach the corresponding patch.
Created attachment 77024 [details] Proposed fix Sorry, I forgot the patch.
Created attachment 77025 [details] Regression test
+1 for 3.3.1 since this is a regression comparing to 3.2 and the fix is low risk.
reopen for 3.3.1
Released for 3.3.1. Regression test added org.eclipse.jdt.core.tests.dom.ASTConverter15Test#test0282
Verified for 3.3.1 using build M20070831-2000
