Bug 50929 - Provide UI for showing call graph affected by flow advice
Summary: Provide UI for showing call graph affected by flow advice
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: IDE (show other bugs)
Version: 1.2   Edit
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Mik Kersten CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-29 20:10 EST by Mik Kersten CLA
Modified: 2007-10-23 05:55 EDT (History)
4 users (show)

See Also:


Attachments
mockup of cflow advice showing up in the outline view (24.85 KB, image/gif)
2004-01-29 20:10 EST, Mik Kersten CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mik Kersten CLA 2004-01-29 20:10:08 EST
The effects of cflow advice can be challenging to infer and currently get no 
help from the tool support.  Now the at the IDEs are starting to show static 
call graphs, we can use this information to give the programmer an idea of the 
execution that will be affected by a cflow advice.  The attached mock-up shows 
a first pass at how this could look in AJDT.
Comment 1 Mik Kersten CLA 2004-01-29 20:10:51 EST
Created attachment 7639 [details]
mockup of cflow advice showing up in the outline view
Comment 2 Eric Bodden CLA 2004-01-30 12:47:01 EST
That looks good for a first approch, I think. However I see two general 
problems: Firstly as you know a static cflow analysis is impossible. That in 
mind, one can easily see that the call hierarchy search that Eclipse uses at the 
moment is very rudimentary sinc eit just works on declared types and does not 
even try to approximate the runtime type. So I don't really know how useful such 
information could be, if one in a lot of cases must fear the information to be 
wrong.
However I tried to integrate some more sophisticated analysis for Elipse last 
summer but did not finish them due to lack of time.
Secondly: Usually we always have a correspondency between advice and adviced 
methods. One can always go back and forth using the annotations. However for a 
cflow I guess nobody would really want to annotate all the methods that could 
possibly be in a specific control flow. That would lead to some kind of 
inconsistency, though not a big one I have to admit.