Package org.aspectj.weaver.patterns

Class HasMemberTypePatternForPerThisMatching

java.lang.Object
org.aspectj.weaver.patterns.PatternNode
org.aspectj.weaver.patterns.TypePattern
org.aspectj.weaver.patterns.HasMemberTypePattern
org.aspectj.weaver.patterns.HasMemberTypePatternForPerThisMatching
All Implemented Interfaces:
IHasPosition, IHasSourceLocation
public class HasMemberTypePatternForPerThisMatching extends HasMemberTypePattern
pr354470. This is a special subtype of HasMemberTypePattern. In order to optimize this situation: 

 aspect X perthis(transactional()) {

 pointcut transactional: execution(@Foo * *(..));

When this occurs we obviously only want an aspect instance when there is a method annotated with @Foo. For a regular execution pointcut we couldn't really do this due to the multiple joinpoint signatures for each joinpoint (and so lots of types get the ajcMightHaveAspect interface). However, for an execution pointcut involving an annotation we can do something clever. Annotations must match against the first primary joinpoint signature - so when computing the type pattern to use for matching when processing the perthis() clause above, we can use the HasMemberTypePattern - because that effectively does what we want. We want an aspect instance if the type hasmethod(...) with the appropriate annotation. This would be great... but breaks in the face of ITDs. If the method that hasmethod() would match is introduced via an ITD we come unstuck, the code in HasMemberTypePattern.hasMethod() does look at ITDs but it won't see annotations, they aren't visible (at least through EclipseResolvedMember objects). And so this subclass is created to say 'if the supertype thinks it is a match, great, but if it doesnt then if there are ITDs on the target, they might match so just say 'true''. Note that returning true is just confirming whether the 'mightHaveAspect' interface (and friends) are getting added.

Author:
Andy Clement