Community
Participate
Working Groups
The code completion engine suggests annotations on places where they are not allowed. For example, in the java editor of a Session Bean in EJB 3.0 project, the code completion engine does not distinguish between class-, method- and field-level annotations. If you type '@L' just before a variable declaration and hit Ctrl+Space, then class-level annotations like "Local" and "LocalHome" will be hinted. If the user chooses one of them, the resulting annotation will be marked as error, because it is not allowed by the compiler on that place. I looked at the code of the org.eclipse.jdt.internal.codeassist.CompletionEngine too see the logic it implements. The CompletionEngine just browses the jars in the classpath to build a list of all available annotations, then matches the result against the typed code completion prefix. That's all. There is no further logic to check if this is the appropriate place to suggest these annotations. I don't see a way for WTP or adopters plugins to change this behavior with a correct one. I think it would be better the CompletionEngine to provide some extension point that would be used by upper layers to contribute the annotations with the corresponding criteria for hinting them.
I presume you are talking about the @Target level for an annotation ? If so, then the same logic used by the compiler to flag inappropriate annotations is available in codeassist engine. I suspect the behavior is explainable by the fact the annotation isn't attached during codeassist to the next element (could be wrong there), and thus discrimination may not occur.
Created attachment 51022 [details] demoproject I attach demo project. The zip file contains a project fake-ejb30. This is a simple Java project with ejb-3_0-api.jar library added in the classpath. To reproduce the problem open FakeEJB.java and try on line 8: 1) Type "@L" and Ctrl+Space --> @Local and @LocalHome annotations are suggested. This is wrong. 2) Type "@" and Ctrl+Space --> No annotation is suggested at all. This is wrong. Example for valid annotation that has to be suggested is @EJB 3) Type "loc" and Ctrl+Space --> @Local annotation is suggested. This is wrong, too - No "@" char is typed before "loc". The result of the code completion is "Local" instead of "@Local". Hope this helps for the identification of the root cause.
Reply to comment 2 The test case is: public class FakeEJB { //completion location private int variable; } 1) Currently code assist doesn't attach the completed annotation to the following element, therefore codeassist is unable to filter an annotation with the wrong target level. But even if the completed annotation was attached to the following element, codeassist must not filter proposals with the wrong target level because the following element can be unrelated with the completion. With this test case: @Target({TYPE}) @interface MyAnnot { } public class FakeEJB { @MyAnn // complete at | location private int variable; } the intent of the user can be to write: public class FakeEJB { @MyAnnot class MemberClass {} private int variable; } However the relevance of these kinds of proposals should be lesser because i think most of the time the user want to add an annotation to the following element. 2) It's fixed in 3.3 M2 (see bug 129983) 3) The completion 'Local' is valid because the it's possible to write the following code: Local l; private int variable; But this proposal should be less relevant than other type proposals because use an annotation type as a variable type is not the common case. We need to improve relevance computation for annotation completion.
As there is several issues described in this bug,, i opened a separate bug for issue 3) bug 184178
Created attachment 64989 [details] Proposed fix for issue 1) With this fix - Annotations which target the same ElementType as the following node are more relevant than others. - Annotations which don't target the same ElementType as the following node are proposed except if the completion is at top level types level. In this case only annotations of types can be possible. package p; @A| public class X {} Currently when the completion is inside the statements part of a method body the completion parser recovery isn't reliable to associate annotations to the correct node. void foo() { @Lo| { int var; So this fix give the same relevance for all annotations inside method body to avoid to compute wrong relevances. This case would be fixed later as it require a deeper completion recovery improvement.
Released for 3.3M7. Test added CompletionTest_1_5#test0301() -> test0329()
Verified for 3.3M7 using I20070427-0010 based on what can be done stated in comment 5. However I found weird to get a proposal for long in case 1) comment 2. Once I take it, I end up with: @long .... and this is wrong. Should I open a bug report for this one ?
Verified.
This is a bug. Base types shouldn't be proposed. Could you open a bug report ?
Closing
