Bug 153966

Summary: Unoptimized matching/weaving for value-binding pointcuts
Product: [Tools] AspectJ Reporter: Eric Bodden <eric>
Component: CompilerAssignee: aspectj inbox <aspectj-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P5 CC: aclement
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Eric Bodden CLA 2006-08-15 14:51:42 EDT 
Hi. Please have a look at the following code snippet:

before(soot.PointsToSet pts): call(* java.util.Map+.put(..)) && args(pts,..) ||
			  call(* java.util.Collection+.add(..)) && args(pts){
  ByteArrayOutputStream bos = new ByteArrayOutputStream();
  new Exception().printStackTrace(new PrintStream(bos));
  String s = bos.toString();
  s = pts.getClass() + "\n" + s;
  if(strings.add(s)) {
    System.err.println(s);
  }
}

By the declared type "PointsToSet" of "pts", it should be clear that this advice can only apply when an object is put into a map or collection which can possibly be a subtype of PointsToSet. However, ajdt shows me that in the line ...

  if(strings.add(s)) {

... there is a match with dynamic residue. This seems wrong. AspectJ should be easily capable of detecting statically that this shadow can never match.
Comment 1 Ron Bodkin CLA 2006-08-15 16:45:54 EDT 
I googled and soot.PointsToSet is an interface. Normally you do need runtime tests whenever there's a test for a class being an instance of an interface. For final types you wouldn't ever need a runtime test... except that AspectJ supports declare parents. If you wove into rt.jar you could use:

declare parents: String implements soot.PointsToSet;

So should AspectJ be making special case assumptions that you aren't weaving into rt.jar? I would argue no, it should not.