Community
Participate
Working Groups
Class file editors do not properly show aspects and throw a few exceptions. This bug is a stub for working through the issues of class file editors and aspects.
I created a BinaryAspectElement and BinaryAspectElemenetInfo classes as a way to ensure that the structure for binary files can be created properly. BinaryAspectElemenetInfo is currently mostly a stub. Most of its methods return empty char arrays instead of proper values. I may need to parse the class file in order to get the correct values.
> I may need to parse the class file in order to get the correct values. Surely not... is this for navigation into a binary file or? From the initial description it isn't clear to me what the problem actually is.
This is to build the structure so that structure will properly appear in the outline view (and it also may help populate the hierarchy view, the call hiearchy view, searches, etc.). I tried getting this information from the IProgramElement associated with the binary aspect (since it is on the aspect path), but there is not enough information in the IProgramElement (such as interfaces, enclosing type, super class, etc). Parsing the class file may not be too difficult. I might be able to subclass ClassFileReader and it might work for my purposes (but it might only show the binary names of the files, although that's better than what we have now).
This comment originially posted on bug 266362 c3: Spent quite a few hours today looking into this and didn?t get as far as I would have liked. Here is what I?ve done: I?ve created a new pointcut and advice the SourceTransformer. This pointcut captures the execution of SourceMapper.mapSource. It ensures that the source that gets mapped is parsable Java (using AspectsConvertingParser). The source mapper is the object that maps class file entities to source file entities and provides source locations. This object is what allows you to navigate to a particular method declaration in a class file. What this means is that declarations in the class file (eg- fields, methods, etc) that are also in the source code can be navigated to, indexed and all that other good stuff. However, this does nothing to help with aspect code (eg- pointcuts, advice, etc). The reason is that pointcuts, advice, etc. either do not exist in the class file, or do so with obscure names. And thus no mapping can occur. There are two other pieces that still have not been implemented. And these two seem like fairly big things, so I need to decide how to continue with this. 1. Building structure--- the build structure operation takes a class file and reads its contents, filling in the proper IJavaElements underneath. As currently implemented, this operation reads the byte code directly. In the byte code, there are no AspectJ elements; they have been converted into Java elements. Two potential solutions and both involve weaving. a. co-opt the entire build structure operation for class files that come from .aj files. Create a new byte code reader that can translate from the compiled Java entities to AJ entities. b. after the normal build structure operation completes, run a second build structure that adds the AJ entities by looking at the original source code. 2. Indexing--- There is a binary indexer that indexes files by reading the byte code directly. There is same problem as above that AJ entities don?t exist in byte code. There are the same two possibilities on how to fix this: a. coopt the entire process and secretly index the AJ source code instead of the byte code. b. index the AJ source code after the actual process completes. For both of these cases, I am leaning towards the ?b? option, but I will need to think about this more.
Fix for c4 has been committed with regression tests. Closing this bug and opening a new one that more specifically states what must be done next.
