Community
Participate
Working Groups
Take this little test case: public interface Marker { String mark(); } public class Foo { public static void main(String[] args) { System.err.println(new Foo().mark()); } } public aspect MarkerAspect { declare parents: Foo implements Marker; public String Marker.mark() { return "Foo"; } pointcut mark(): execution(public String mark()) && within(Marker+); String around() : mark() { System.err.println(thisJoinPoint); return proceed(); } } The around advice in the MarkerAdvice does not match the introduced method mark. I think it should.
Changing OS from Mac OS to Mac OS X as per bug 185991
This behavior is correct as I understand it. Within deals with lexical structure, not typing. You can use this(Marker) to match methods defined on Marker. It is a little surprising that this is withincode(String Marker.mark()) but I think it's useful to have the current AspectJ semantics. Per http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html "The within pointcut picks out each join point where the code executing is defined in the declaration of one of the types in TypePattern." Clearly mark is defined lexically within MarkerAspect and NOT within a subtype of Marker.
For the given test case I see no problem at all in using this(Marker). But unfortunately the provided test case is too much condensed. Actually we wanted to use the pertypewithin instantiation model for an apsect. This aspect should then transparently be applied to Marker's regardless whether the interface and implementation of Marker were introduced or not. In this scenario we now loose this transparency. Writing aspect libraries we now have to consider the pertypewithin instantiation model more carefully. In some cases this means we can not use it at all and have to use our own per type management. I considered within from the byte code perspective. And I was surprised that although there is a mark() definition in Foo it is not matched.
clarify for 1.5.4
within() is working as designed (lexical scoping) pertypewithin() is based on that, so working as designed. I basically understand Vincenz' point. Whether the member is introduced via an ITD can make a difference as to whether a pertypewithin related aspect would catch the execution of a method. I'm not sure how to proceed with the bug - it seems like there could be an enhancement in this area but I'd need multiple compelling use cases to justify any work done.
