Bug 341130 - Inadvertent change in matching (inherited annotations)
Summary: Inadvertent change in matching (inherited annotations)
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P2 major (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 341390
  Show dependency tree
 
Reported: 2011-03-28 12:14 EDT by Andrew Clement CLA
Modified: 2013-06-24 11:03 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Clement CLA 2011-03-28 12:14:30 EDT
This has happened due to the refactoring/improvement work in 1.6.7 that introduced fast matching.

This program:


@MXBean
interface Intface {
 void m();
}

class C implements Intface {
 public void m() {}
}

aspect X {
 before():execution(* (@MXBean *).*(..)) {}
}

shows a match for the advice against method m() with < 1.6.7 but it is not a match with more recent compilers.  This is due to the fast match implementation for declaring type in an execution pointcut.  It is more strictly following the rule that annotations are not inherited down the interface chain.  However, it is clearly a nice use case, and by the rule of multiple signatures, the joinpoint for m() has two signatures:

void C.m()
void Intface.m()

And in the case of that second one, the Intface is annotated.  So should the advice match?  When used at other positions (e.g. execution(@Foo * *(..))) we clearly indicate that these annotations match on the subject of the joinpoint (i.e. the main joinpoint signature) and no other signatures.  It is not clearly spelled out for annotations used in the declaring type position.

bug 292239 surfaced this problem.
Comment 1 Andrew Clement CLA 2013-06-24 11:03:28 EDT
unsetting the target field which is currently set for something already released