aboutsummaryrefslogtreecommitdiffstats
path: root/docs/adk15ProgGuideDB/joinpointsignatures.adoc
blob: d8bf63c4dcd18f35d42962b4e135f5a6a5d91881 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
[[jpsigs]]
== 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:

....
call(ModifierPattern TypePattern TypePattern.IdPattern(TypePatternList) ThrowsPattern)
....

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_:

[arabic]
. 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]]
=== 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.

[cols=",,,,,,",options="header",]
|===
|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 execution 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):

....
T t = new T();
t.m("hello");  <= call join point occurs when this line is executed
....

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`:

....
interface Q {
  R m(String s);
}

class P implements Q {
  R m(String s) {...}
}

class S extends P {
  R' m(String s) {...}
}

class T extends S {}
....

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

....
R' S.m(String)
R  P.m(String)
R  Q.m(String)
....

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:

....
interface Q {
  R m(String s);
}

class P implements Q {
  R m(String s) {...}
}

class S extends P {
  R' m(String s) {...}
}

class T extends S { }

class U extends T {
  R' m(String s) {...}
}
....

Then the execution join point signatures arising as a result of the call
to `u.m("hello")` are:

....
R' U.m(String)
R' S.m(String)
R  P.m(String)
R  Q.m(String)
....

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:

....
class P  {
  F f;
}

class S extends P {
  F f;
}

class T extends S { }
....

Then the join point signatures for a field get join point of the field
`f` on an object with declared type `T` are:

....
F S.f
F T.f
....

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.

[cols=",",options="header",]
|===
|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

....
public class X {
  @Foo
  protected void doIt() {...}
}

public class Y extends X {
  public void doIt() {...}
}
....

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}`.

[[join-point-matching-summary]]
=== 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_:

[arabic]
. 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

....
interface Q {
  R m(String s);
}

class P implements Q {
  @Foo
  public R m(String s) {...}
}

class S extends P {
  @Bar
  public R' m(String s) {...}
}

class T extends S {}
....

and the program fragment:

....
P p = new P();
S s = new S();
T t = new T();
...
p.m("hello");
s.m("hello");
t.m("hello");
....

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.