Community
Participate
Working Groups
The JDTWorld opens up many possibilities for AJDT to generate a crosscutting model for source code (and maybe binary code) that is not on the classpath. AJDT accesses the AspectJ crosscutting model through AJDT's AJProjectModelFacade class, which in turn accesses the IHierarchy and IRelationshipMap types to get at crosscutting structure. As much as possible, keeping this architecture would be a way to partition the impact on AJDT itself. So, a short description of what I would like to do and then a suggestion on a possible implementation. What I'd like: AJDT does not have crosscutting relationships for elements that are woven during LTW. Also, relationships to elements on the in path are non-existent (even though the opposite end of the relationships (ie- *from* elements on the in path do exist)). I would like AJDT to be able to add these relationships to its project model. There are two parts to this: 1. creating the hierarchy for elements that should be matched, but are not on the classpath (eg- LTW projects/jars/folders, in path projects/jars/folders). 2. determining where the matches are. I am considering matching to be two directional. If my project matches into something on its LTW path, then the thing on the LTW path also matches into my project. I would like to see minimal duplication of hierarchies. There are several cases here: 1. Project A has Project B on LTW path---each project has its own hierarchy, with their own handles, so there should be no duplication of handles. The relationship map mus be able to properly reference across projects. Since both ends are source code, a JDT World is probably appropriate here. 2. Project A has Jar/binary folder B on its LTW path---Project A must include the hierarchy of jar B and use binary style handles. This would probably require a ReflectionWorld object to perform the matching. 3. Project A has Project B on its in path---In this case Project A has relationships coming *from* project B in its relationship map already. We want to populate the Relationship map of project B with elements from Project A. This is something that would happen during builds of Project B. Somehow (perhaps manually at first) project B must be made aware of and listen for changes to project A. When there is a change, project B must update its relationship map accordingly. Note that neither Project A's hierarchy nor Project B's hierarchy contains elements of the other project. 4. Project A has Jar B on its in path---again, Project A has incoming relationships *from* Jar B, but the reverse is not true. Would need a ReflectionWorld to create the reverse end of the relationship. Note that I need to be a bit more clear about who controls which end of the relationship. Each relationship has two sides, and when one side changes, so must the other side. A simplification is that Project A controls the end of the relationship that originates from Project A, and Project B does so for the other end of the relationships. Project A controls the end of the relationship that *originates* in Binary B (this is because the other end of the relationship that originates in the source of Project A is already controlled by AspectJ). So, what this means is that AJDT would need to be able to: 1. create JDTWorld and ReflectionWorld objects for interesting projects/binaries 2. know when to update or recreate them (eg- when an interesting project changes, or when a binary changes) 3. generate an IHierarchy object from the World object (for ReflectionWorld objects only) 4. generate an IRelationshipMap object for the relationships between Project A and Project/Binary B.
Initial comments from me. I'm glad you are putting some brain cycles into thinking about this. > The JDTWorld opens up many possibilities for AJDT to generate a crosscutting > model for source code (and maybe binary code) that is not on the classpath. A world is just about resolving types and answering questions - what is my visibility? what are my members? So far we have a BcelWorld (for bytecode), a ReflectionWorld (for bytecode) and in the future a JDTWorld (for source code, purely to save the cost of compilation). None of the worlds know how to populate a model - currently there exists one visitor in the compilation phase that builds the structure for a file based on internal JDT compiler artifacts (not the Ast or IJavaElement stuff) and one hacked visitor in the weaver that partially faults in aspects to bring the aspectpath to life. So alongside a JDTWorld, there would need to be a visitor that brings JDT shaped things into the model - there is no enhancement open for that, but looks like it would be required. Also one for bringing in bytecode based material - possibly based on the existing aspect-faulting one but improved greatly. It might well be that the world abstraction is reliable enough that the visitor could be the same for any world, but I'm not sure. > AJDT accesses the AspectJ crosscutting model through AJDT's > AJProjectModelFacade class, which in turn accesses the IHierarchy and > IRelationshipMap types to get at crosscutting structure. As much as possible, > keeping this architecture would be a way to partition the impact on AJDT > itself. Yep, it would be nice to hide it behind that facade. > AJDT does not have crosscutting relationships for elements that are woven > during LTW. Also, relationships to elements on the in path are non-existent > (even though the opposite end of the relationships (ie- *from* elements on the > in path do exist)). The non-existent inpath relationships are due to the lack of model building capabilities for binary code. I worry about confusing two use cases here: ltw and inpath. I might treat them as separate scenarios and see if they have anything in common once partially designed rather than trying to design something up front that suits both. > 1. creating the hierarchy for elements that should be matched, but are not on > the classpath (eg- LTW projects/jars/folders, in path projects/jars/folders). These are the missing visitors - there are no enhancement requests open for these. If it is a project then use the JDT visitor, if it is a jar or class file folder, use the bytecode visitor. (unless we can have a common visitor, as mentioned above) I have raised bug 265083 to cover an attempt to create a common visitor (relatively nice self contained project actually). 1a. 'type walker' (for want of a better name) than can walk the structures and expose join points for matching. The join points should be exactly the same as if the code was presented by the bcel type walker. The type walker for JDT World is mentioned in step 2 of bug 265041. There is no open enhancement for a bytecode walker - the bcel one could be teased out to a reusable entity but care would have to be taken not to damage current performance. It will not be possible to build a reusable walker that will operate on any world since it will need intimate knowledge of the internal details of whatever it is dealing with in order to create all join points. Bug 265041 can cover creation of the JDT type walker. I have raised bug 265084 to cover creation of a basic bytecode walker. > I would like to see minimal duplication of hierarchies. Yep, one model per project, per jar or class folder would be excellent > There are several cases here: > 1. Project A has Project B on LTW path---each project has its own hierarchy, > with their own handles, so there should be no duplication of handles. The > relationship map mus be able to properly reference across projects. Since > both ends are source code, a JDT World is probably appropriate here. Not sure about this LTW path, I would think hard about alternatives before proposing yet another path. Users have trouble comprehending the 3 we have already (classpath, inpath, aspectpath). > 3. Project A has Project B on its in path---In this case Project A has > relationships coming *from* project B in its relationship map already. We > want to populate the Relationship map of project B with elements from > Project A. > This is something that would happen during builds of Project B. Somehow > (perhaps manually at first) project B must be made aware of and listen for > changes to project A. When there is a change, project B must update its > relationship map accordingly. Note that neither Project A's hierarchy nor > Project B's hierarchy contains elements of the other project. I'd break out inpath handling to a separate enhancement I think. Seems like there are a bunch of other enhancement requests that this has driven - i've raised them but when they'll get done, I'm not sure. I'd also try and tackle just ltw or just inpath but not both at once. The inpath story seems clearer since we already have that path and people are using it. The ltw story is not - I am not sure what people want. We should talk more about the LTW path proposal.
With regards to LTW and in path, makes sense that we don't want to overgeneralize just yet. The reason why I have been thinking about them together so far is that I see LTW path and in path as just a bunch of stuff that we need to match with. The only functional difference that I can see is that the in path is also on the classpath (but don't know if that really matters). Since the in path has a clearer implementation and use case, would it make sense to focus on this first as a way to hint at an implementation for LTW?
unsetting the target field which is currently set for something already released
