Community
Participate
Working Groups
Currently AJDT shows cross-cutting based on the aspect that defines the advice (which may be abstract) rather than the (concrete) aspect that implements it. This is misleading. The attached projects show 2 examples where this is problematic. Example 1: Project1 defines an abstract aspect which is extended and made concrete in Project2. The Editor view for project2.HelloWorld attributes cross-cutting to the abstract aspect but neither the Outline view for the abstract nor the concrete aspects shows any cross-cutting. The Visualiser views are empty. Example 2: Project3 defines an abstract aspect and 2 concrete sub-aspects. All views attribute the cross-cutting of project3.HelloWorld to the abstract aspect and misleadingly hide the duplicate advice in the 2 concrete sub-aspects. In each example cross-cutting should be attributed to concrete aspects and all concrete aspects should appear in the Visualiser.
Created attachment 15858 [details] Examples
Let's tackle Example 2 first. I've set those sources up as a test case in AspectJ since this will involve changes there. Let me know what you think of adding the following relations: abstract pointcut scope(); -> concretized by - ConcreteAspect1.scope(): ... - ConcreteAspect2.scope(): ... And then the back links will be called "concretizes". We can not show "advises" links for pointcuts, because pointcuts don't cause advice to execute. So this would make it possible to navigate that structure without violating that constraint. Let me know if that would work, and if it could result in a sensible UI for the Visualiser.
Yes, I believe we need the "concretizes" relationship, although if anyone has suggestions for a nicer name, I'd like to hear it!
I just double-checked with Gregor and we believe that there is no better name for that concept. I believe that it will be obvious enough for programmers especially since it will appear in conjunction with the keyword "abstract". I'll take this on, and move it to AspectJ since it will be implemented in the ASM. Once that's done we can have a discussion on how this should surface in AJDT. One idea is that we add an Outline filter button that toggles the visibility of the "uses pointcut" and "concretizes" relations. If might prototype that alongside the change, in which case I'll raise a seperate enhancement report.
This is not really what I had in mind for the Visualiser. It shows the relationship between Aspects and types. It is not concerned with pointcuts. It is my understanding that types are cross-cut by concrete aspects not abstract ones even if that is where advice is declared. The situation may be slightly different for gutter annotations and the outline view which shows the relationship between join points and advice as well as advice and pointcuts. I would like to see a tree view in the Visualiser Menu showing aspect relationships (parent->child) and the bars in the Visualiser View using the colour associated with the _concrete_ aspect rather than and abstract one. If advice/pointcuts are actully declared in an abstract parent the tree view facilitates navigation.
Two issues have come out of this: 1. Showing the concretizes relationship in the editor and outline view, to allow nagivation between abstract and concrete aspects in the editor/outline view. 2. What to show in the visualiser, where we want to show the higher level relationship between aspects and classes. Here it probably makes more sense for the source of the relationship to be the concrete aspect rather than the abstract aspect is it is currently. So let's leave this bug for item 1, and I've raised bug 79283 for item 2 (which may itself require ASM changes, but is really a separate issue).
Yes, let's have this bug deal with (1) alone. But I'll address Matthew's point (2) here as well. I understand why this can be a desirable way of looking at how abstract/concrete aspects affect the system. However, we need to be very careful here about how the tools communicate the semantics of the language. First, types are not crosscut by aspects, just as types don't call types. Advice crosscuts dynamic join points. That advice is contained by an aspect, and the shadows of the join points may be contained by a file. The Aspect Visualiser does a somewhat strange thing by grouping all of the advice in a single aspect, but this grouping let's you think more abstractly about advice so it's a useful thing. What you are proposing is to change this grouping of advice to be something much more complex, by conceptually moving the advice from the abstract aspect onto each of the concrete aspects. Keeping in mind our important decision that pointcuts do not show up as "affects" links in the structure model, since they have no behavioral effect on the system. So on first examination I'm guessing that this proposal will cause a mismatch between what the tool shows and the aspect inheritance semantics of pointcuts and advice. What would be useful is if you could come up with a small example of when this structure results in the Visualiser links being more useful and more clear about the crosscutting structure. Please make sure to include more than one concrete aspect in the example
My grasp of AOP terms is still maturing ;-). An aspect is the modularization of a cross-cutting concern. The Visualiser illustrates how that concern cross- cuts your application (either the hand-coded form through declare error/warning and the AO implementation through pointcuts & advice or ITDs). Its primary purpose is to help verify the correctness of your aspects both as they relate to the application and each other. It is also a good way to determine what aspects affect you system. Currently it doesn't do this properly because it doesn't show aspects that inherit all their advice. If I have 2 concrete aspects the Visualiser should look the same regardless of whether those aspects share a common super-aspect or not. It should show me whether the implementation is correct: are there gaps or overlap. Where the advice is declared is not important.
Created attachment 16128 [details] Example The Visualiser should show SubAspect1 and ConcreteAspect1 in the same way because the implement the same cross-cutting. Also for SubAspect2 and ConcreteAspect2. Merely showing AbstractAspect hides the fact that there are 2 separate concerns.
*** Bug 84030 has been marked as a duplicate of this bug. ***
We really need to get AJDT as solid as possible. this is a good issue to resolve in aj5m3 timeframe.
*no* chance for m3
We're not going to hold 1.5.0 for this, but will make it a top priority for post 1.5.0. Given that the use case for this is AJDT, that should still mean that we can surface this function to end users ahead of the 1.5.1 release of the compiler if we need to.
some thinking on this the other day came up with us having no idea what to do .. didnt make 1.5.1 ;)
Just as a note.....any work done in this space needs to be extended to the faulted in model for injar aspects (see bug 145963, bug 160469 and ShadowMunger.createHierarchy()).
