[aosd-discuss] Call vs. execution pointcuts in AspectJ
adrian_colyer at uk.ibm.com
Mon Jan 31 06:26:52 EST 2005
> 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..*(..)) &&
> 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
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
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(* *.*(..)) &&
Adrian_Colyer at uk.ibm.com
Pascal Costanza <pc at p-cos.net>
Sent by: discuss-bounces at aosd.net
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
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
> I appreciate your comments.
What concrete examples do you have mind that make one or more of those
options applicable / preferable?
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...
More information about the discuss