Join Point Signatures
Many of the extensions to the AspectJ language to address the new features of
Java 5 are derived from a simple set of principles for join point
matching. In this section, we outline these principles as a foundation
for understanding the matching rules in the presence of annotations,
generics, covariance, varargs, and autoboxing.
Join Point Matching
AspectJ supports 11 different kinds of join points. These are
the method call, method execution, constructor call,
constructor execution, field get, field set, pre-initialization,
initialization, static initialization, handler, and
advice execution join points.
The kinded pointcut designators match
based on the kind of a join point. These are the call,
execution, get, set, preinitialization, initialization,
staticinitialization, handler, and adviceexecution
designators.
A kinded pointcut is written using patterns, some of which
match based on signature, and some of which
match based on modifiers. For example, in
the call pointcut designator:
the modifiers matching patterns are ModifierPattern
and ThrowsPattern, and the signature matching patterns
are TypePattern TypePattern.IdPattern(TypePatternList).
A join point has potentially multiple signatures, but only one set of
modifiers. A kinded primitive pointcut matches a particular join point
if and only if:
They are of the same kind
The signature pattern (exactly) matches at least one
signature of the join point
The modifiers pattern matches the modifiers of the
subject of the join point
These rules make it very easily to quickly determine whether a
given pointcut matches a given join point. In the next two sections,
we describe what the signature(s) of a join point are, and what the
subjects of join points are.
Join Point Signatures
Call, execution, get, and set join points may potentially have multiple
signatures. All other join points have exactly one signature. The
following table summarizes the constituent parts of a join point
signature for the different kinds of join point.
Join Point Kind
Return Type
Declaring Type
Id
Parameter Types
Field Type
Exception Type
Method call
+
+
+
+
Method execution
+
+
+
+
Constructor call
+
+
Constructor execution
+
+
Field get
+
+
+
Field set
+
+
+
Pre-initialization
+
+
Initialization
+
+
Static initialization
+
Handler
+
Advice execution
+
+
Note that whilst an advice excetution join point has a
signature comprising the declaring type of the advice and the
advice parameter types, the adviceexecution
pointcut designator does not support matching based on this
signature.
The signatures for most of the join point kinds should be
self-explanatory, except for field get and set, and method call and execution
join points, which can have multiple signatures. Each signature of
a method call or execution join point has the same id and parameter
types, but the declaring type and return type (with covariance) may vary.
Each signature of a field get or set join point has the same id and field
type, but the declaring type may vary.
The following sections examine signatures for these join points
in more detail.
Method call join point signatures
For a call join point where a call is made to a method
m(parameter_types) on a target type T (where
T is the static type of the target):
Then the signature R(T) T.m(parameter_types) is a signature
of the call join point, where R(T) is the return
type of m in T, and
parameter_types are the parameter types of
m. If T itself does not
declare a definition of m(parameter_types), then
R(T) is the return type in the definition of
m that T inherits. Given the
call above, and the definition of T.m:
Then R' T.m(String) is a signature of the
call join point for t.m("hello").
For each ancestor (super-type) A of T,
if m(parameter_types) is defined for that super-type, then
R(A) A.m(parameter_types) is a signature of the call join
point, where R(A) is the return type of
m(parameter_types) as defined in A, or as inherited
by A if A itself does not
provide a definition of m(parameter_types).
Continuing the example from above,we can deduce that
are all additional signatures for the call join point arising
from the call t.m("hello"). Thus this call
join point has four signatures in total. Every signature has the same
id and parameter types, and a different declaring type.
Method execution join point signatures
Join point signatures for execution join points are defined
in a similar manner to signatures for call join points. Given the
hierarchy:
Then the execution join point signatures arising as a result
of the call to u.m("hello") are:
Each signature has the same id and parameter types, and a
different declaring type. There is one signature for each type
that provides its own declaration of the method. Hence in this
example there is no signature R' T.m(String)
as T does not provide its own declaration of
the method.
Field get and set join point signatures
For a field get join point where an access is made to a field
f of type F
on a object with declared type T, then
F T.f is a signature of the get join point.
If T does not directly declare a member
f, then for each super type S
of T, up to and including the most specific
super type of T that does declare the member
f, F S.f is a signature
of the join point. For example, given the hierarchy:
Then the join point signatures for a field get join point of
the field f on an object with declared type
T are:
The signatures for a field set join point are derived in an
identical manner.
Join Point Modifiers
Every join point has a single set of modifiers - these include
the standard Java modifiers such as public, private,
static, abstract etc., any annotations, and the throws
clauses of methods and constructors. These modifiers are the
modifiers of the subject of the join point.
The following table defines the join point subject for each kind
of join point.
Join Point Kind
Subject
Method call
The method picked out by Java as
the static target of the method call.
Method execution
The method that is executing.
Constructor call
The constructor being called.
Constructor execution
The constructor executing.
Field get
The field being accessed.
Field set
The field being set.
Pre-initialization
The first constructor executing in
this constructor chain.
Initialization
The first constructor executing in
this constructor chain.
Static initialization
The type being initialized.
Handler
The declared type of the
exception being handled.
Advice execution
The advice being executed.
For example, given the following types
Then the modifiers for a call to (Y y) y.doIt()
are simply {public}. The modifiers for a call to
(X x) x.doIt() are {@Foo,protected}.
Summary of Join Point Matching
A join point has potentially multiple signatures, but only one set of
modifiers. A kinded primitive pointcut matches a particular join point
if and only if:
They are of the same kind
The signature pattern (exactly) matches at least one
signature of the join point
The modifiers pattern matches the modifiers of the
subject of the join point
Given the hierarchy
and the program fragment:
The the pointcut call(@Foo R P.m(String)) matches the
call p.m("hello") since both the signature and the
modifiers match. It does not match the call s.m("hello")
because even though the signature pattern matches one of the signatures
of the join point, the modifiers pattern does not match the modifiers of
the method m in S which is the static target of the call.
The pointcut call(R' m(String)) matches the
calls t.m("hello") and s.m("hello").
It does not match the call p.m("hello") since the
signature pattern does not match any signature for the call join point
of m in P.