[aosd-discuss] Call vs. execution pointcuts in AspectJ

[Adrian Colyer]

> My impression is that the notion of call pointcuts is an artifact that 
> stems from the fact that AspectJ initially couldn't statically weave 
> advices to third-party libraries or the core API of Java.

This is absolutely not the case. A call join point  is different to an 
execution join point in at least one very important way, it captures the 
call site, so you can say things like:

pointcut daoCallFromModel() : call(* org.xyz.dao..*(..)) && 
within(org.xyz.model..*);

> Barzilay's et al.'s note that the semantics of call pointcuts change as 
> soon as you compile for a JDK 1.4 virtual machine also is a strong hint 
> that the result is more or less accidental.

The semantics of call pointcuts did not change. One of the design goals in 
AspectJ is that you should get consistent results regardless of whether 
you compile from source, or perform binary weaving. For this reason, the 
semantics are defined in terms of the static target of the call, as 
represented in the bytecode. When the bytecode changed with -target 1.4, 
the join points therefore changed and hence call matched different join 
points, but with the exact same semantics.

Barzilay et al.'s paper was written at the AspectJ 1.1.1 level as I 
recall. See the AspectJ 1.2 README 
(http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/README-12.html) 
for a description of changes made in that release to catch potentially 
confusing uses of call, and also a description of the Java 1.3 -> 1.4 
change and its impact on AspectJ programs.

The key to understanding pointcut matching is to remember that pointcuts 
match join points. Pointcuts don't match method signatures, or places in 
the code...  As part of the Java 5 work we're doing in AspectJ, we wrote a 
new chapter at the start of the AspectJ 5 Developer's Notebook 
(http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/ajdk15notebook/index.html) 
that explains the join point matching rules - particularly in the case of 
call.   I hope this doc will make things clearer for readers.

Finally remember that AspectJ lets you express both static or dynamic 
typing based matching using "call(* Foo.*(..))" and "call(* *.*(..)) && 
target(Foo)" respectively.

Regards, Adrian.

-- Adrian
Adrian_Colyer at uk.ibm.com



Pascal Costanza <pc at p-cos.net> 
Sent by: discuss-bounces at aosd.net
31/01/2005 09:48

To

cc

Subject
Re: [aosd-discuss] Call vs. execution pointcuts in AspectJ







On 30 Jan 2005, at 15:57, Michael Schuerig wrote:

> Starting with my first contact with AspectJ I've always been a bit
> mystified by the difference between call and execution pointcuts, apart
> from the obvious one that the former matches at the caller, the latter
> at the callee side of things.

My impression is that the notion of call pointcuts is an artifact that 
stems from the fact that AspectJ initially couldn't statically weave 
advices to third-party libraries or the core API of Java. (Load-time 
weaving / bytecode weaving was introduced only later, if I remember 
correctly.)

So assume you have a third-party class C and you want to add some 
advice to a method m that is defined in it. Then the only chance to do 
that if you cannot change C itself is to manipulate all the call sites. 
I don't think there is much more to this issue than that.

Barzilay's et al.'s note that the semantics of call pointcuts change as 
soon as you compile for a JDK 1.4 virtual machine also is a strong hint 
that the result is more or less accidental. Indeed, Sun slightly 
changed the way method invocations are encoded in bytecode: Before 1.4, 
the method signature was required to name the class in which a method 
was originally defined whereas from 1.4 on the requirements were 
relaxed. (The old requirement only makes the Java compiler a bit more 
complicated but doesn't add anything useful to the table.) I guess that 
the AspectJ compiler just reuses the information from those method call 
signatures, which would explain the change in semantics.

> To this end, I'd like to suggest a further option, not covered by
> Barzilay et al. (if I understand them correctly). In message-passing
> parlance, the invocation of a method can be divided into two distinct
> events: (1) The caller sends a message to a target object, (2) the
> target object selects and executes a specific method implementation to
> execute (mut. mut. for generic functions). Now, I'd like to capture
> these different kinds of events with different pointcuts.
>
> Thus, a call pointcut should match based on the dynamic type of the
> target -- "broad" and "dynamic" in the terms of Barzilay et al. On the
> other hand, an execution pointcut should statically match a specific
> method implementation. In the latter case, the dynamic type of the
> target object is of no concern, as long as the specific method is not
> overridden.
>
> I appreciate your comments.

What concrete examples do you have mind that make one or more of those 
options applicable / preferable?


Pascal

--
Standards are only useful when they're standardising on something you'd 
actually want to do. - Daniel Barlow


__________________________________________________
AOSD Discuss mailing list    -    discuss at aosd.net
To unsubscribe go to http://aosd.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/discuss_aosd.net/attachments/20050131/310e05b2/attachment.htm