Call and Execution Semantics in AspectJ

Call and Execution Semantics in AspectJ

Ohad BarzilayYishai A. FeldmanShmuel TyszberowiczAmiram Yehudai

Call and Execution Semantics in AspectJ, FOAL 2004 2

Agenda

Describe the current semantics of AspectJ call and execution join points with respect to inheritance

Argue with the semantics of some of these constructs

Suggest some alternative semantics Discuss the expressive power of the

alternatives


Scope of discussion From the AspectJ Programming Guide:

“call(MethodPattern):Picks out each method call join pointwhose signature matches MethodPattern”

The semantics of “matches”:• Based on which type?

• Type of the object?

• Type of the reference?

• Does the match include subclasses as well?

• …


Motivation

Automatically generated AOP code JOSE tool – enforcement of Design by

Contract methodology using AspectJ


Class hierarchy

public class A1 { public void f() {} public void g() {}}

public class A2 extends A1 { public void h() {}}

public class A3 extends A2 { public void f() {}}

A1

f()

g()

A3

f()

A2

h()


Calling who?

pointcut call(void A1.f())s1.f()s3.f()s1d3.f()

pointcut call(void A1.g()) s1.g()s3.g()s1d3.g()

A1 s1 = new A1();A3 s3 = new A3();A1 s1d3 = new A3();

A1

f()

g()

A3

f()

A2

h()


Calling who?




A1

f()

g()

A3

f()

A2

h()


Calling who?



What is the ‘+’ modifier for?


A1

f()

g()

A3

f()

A2

h()


Calling who?

pointcut call(void A3.f())s3.f()

s1d3.f()

The match here was based on the static type of the reference

Not consistent with java


A1

f()

g()

A3

f()

A2

h()


Calling who?

pointcut call(void A3.g()) s1.g() s1d3.g() s3.g()

Does not capture any of our join points

g() was not lexically defined in A3

Not consistent with java


A1

f()

g()

A3

f()

A2

h()


The call model

Notation:• pointcut

• variable defined as

• join point

call(void . ())cpc C f = new ()S x D

. ()jp x f


The call model



• join point

For this to compile


. ()jp x f

D S


The call model



• join point

For this to compile And we get:


. ()jp x f

is lexically defined in cjp pc S C f C

D S


Executing what?

pointcut execution(void A1.f())s1.f()s3.f()s1d3.f()


A1

f()

g()

A3

f()

A2

h()


Executing what?

pointcut execution(void A1.f())s1.f()s3.f()s1d3.f()

The execution of f() from inside A3 matched A1.f()• Reasonable for call

• Surprising for execution


A1

f()

g()

A3

f()

A2

h()


Executing what?

Almost the same as call

But: s1d3.f()

execution(void A3.f())

call(void A3.f())

call and execution differ in more than just their context


A1

f()

g()

A3

f()

A2

h()


call vs. execution

From the AspectJ Programming Guide:“The rule of thumb is that if you want to pick

a join point that runs when an actual piece of code runs (as is often the case for tracing), use execution, but if you want to pick one that runs when a particular signature is called (as is often the case for production aspects), use call.”

No!


The execution model



• join point

execution(void . ())epc C f = new ()S x D

. ()jp x f


The execution model



• join point

And we get:

execution(void . ())epc C f = new ()S x D

. ()jp x f

is lexically defined in ejp pc D C f C


Running in the family

s3.h() call(void A1+.h())

call(void A3+.h())

Consistent, but surprising due to previous problems


A1

f()

g()

A3

f()

A2

h()


The subtype pattern model Notation:

• call pointcut

• execution pointcut


• join point

call(void . ())cpc C f

= new ()S x D. ()jp x f

execution(void . ())epc C f


The subtype pattern model Notation:

• call pointcut

• execution pointcut


• join point

And we get:

call(void . ())cpc C f


is lexically defined in some s.t. cjp pc S C

f F S F C

execution(void . ())epc C f

is lexically defined in some s.t. ejp pc C

f F

D

D F C


Summary

Intuitive:• Pointcuts with subtype patterns are equivalent

to the union of all pointcuts with subtypes substituted for the given type.

• The semantics of execution pointcuts is based on the dynamic type of the target.


Summary

Unintuitive:• The semantics of call pointcuts depends on

the static type of the target.

• Call and execution pointcuts only capture join points for classes where the given method is lexically defined.

• As a result of this, the difference between pointcuts with or without subtype patterns is subtle and unintuitive.


Alternative semantics

In our opinion, the lexical definition requirement should be removed

Two questions remain:1. Should subclasses be included when the

subtype pattern modifier does not appear in the pointcut? (“narrow” vs. “broad”)

2. Should call join points based on their “static” or “dynamic” type?


call pointcut in the proposed semantics call(void . ())cpc C f


exists in C f CS exists in C f CS

exists in C f CD exists in C f CD

Narrow Broad

Static

Dynamic

...cjp pc


Alternative semantics

Each of the four semantics is consistent and reasonable

Perhaps the broad–dynamic semantics best reflects object oriented principles, in that a reference to a class includes its subclasses

AspectJ has other constructs to get the desired behavior• within()

• target()


Bottom line

A starting point for a discussion of desired AspectJ semantics

Driving force should be user needs

Common tasks should be simple

• Use other pointcut specifiers for less common tasks

Should conform with OOP methodology

Should be internally consistent


Related workA Calculus of Untyped Aspect-Oriented Programs

R. Jagadeesan, A. Jeffrey, and J. Reily

A Theory of AspectsD. Walker, S. Zdancewic, and J. Ligatti

A Semantical Approach to Method-Call InterceptionR. Lämmel

Compilation semantics of aspect-oriented programs H. Masuhara, G. Kiczales, and C. Dutchyn

A semantics for pointcuts and advice in higher-order languagesD. B. Tucker and S. Krishnamurthi

A semantics for advice and dynamic join points in aspect-oriented Programming

M. Wand, G. Kiczales, and C. Dutchyn

Questions ?

A Discussion

Call and Execution Semantics in AspectJ

Documents

Transcript of Call and Execution Semantics in AspectJ