Community
Participate
Working Groups
Using a library compiled with the AJC-compiler within a pure java project gives some annoying effects. Within the content-assistance (which shows all of the methods available to the working object), the methods introduced using AspectJ are not shown. However when I check the declared methods (using java-reflection) for the class to which this object applies, these methods can be found. I think this is a strange problem since I thought the content-assisting functionality in JDT also used the java-reflection. Again within the same content-assistence, I can see lots of public final variables with the very cryptic AJC-names, and a some methods with analog names. Isn't it possible to make this variables not public (and possibly not even protected) so these variables will not crowd the content-assisting functionality in JDT. I think this is a major problem, since in some classes (the classes in which I use AspectJ), the amount of such uninteresting fields and methods is larger than the actual usefull fields and methods. Both problems make it much harder to program using an AspectJ-compiled library within a pure java-project. greetings, Koen Casier
Moved to AJDT project. We plan to fix this in the Lancaster release.
I've just checked in a change that improves the situation. You will now get code completion for elements from .aj files in qualified context. For example: Aspect a = ...; a. <- code complete here will contain the visible members of Aspect a
*** Bug 70712 has been marked as a duplicate of this bug. ***
All the completion proposals beginning with ajc$ get filtered in 1.2.0 M1 so the artefacts mentioned by Koen Casier aren't visible any more. -> fixed (for other issues related to code completion, I've opened bug 74419)
