aboutsummaryrefslogtreecommitdiffstats
path: root/docs/adk15ProgGuideDB/joinpointsignatures.xml
blob: d5b618e6d1c2f3b32a080c2c01d390a8c9bea244 (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
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
<chapter id="jpsigs" xreflabel="Join Point Signatures">

  <title>Join Point Signatures</title>

    <para>
        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.
    </para>
  
    <sect1 id="join-point-matching">
        <title>Join Point Matching</title>
    
        <para>AspectJ supports 11 different kinds of join points. These are
        the <literal>method call, method execution, constructor call,
        constructor execution, field get, field set, pre-initialization,
        initialization, static initialization, handler,</literal> and
        <literal>advice execution</literal> join points.</para>
        
        <para>The <emphasis>kinded</emphasis> pointcut designators match
        based on the kind of a join point. These are the <literal>call,
        execution, get, set, preinitialization, initialization, 
        staticinitialization, handler,</literal> and <literal>adviceexecution</literal>
        designators.</para>
        
        <para>A kinded pointcut is written using patterns, some of which 
        match based on <emphasis>signature</emphasis>, and some of which
        match based on <emphasis>modifiers</emphasis>. For example, in 
        the <literal>call</literal> pointcut designator:</para>
        
        <programlisting><![CDATA[
        call(ModifierPattern TypePattern TypePattern.IdPattern(TypePatternList) ThrowsPattern)
		]]></programlisting>
		
		<para>the modifiers matching patterns are <literal>ModifierPattern</literal>
		and <literal>ThrowsPattern</literal>, and the signature matching patterns
		are <literal>TypePattern TypePattern.IdPattern(TypePatternList)</literal>.
		</para>
		
		<para>
		A join point has potentially multiple signatures, but only one set of
		modifiers. <emphasis>A kinded primitive pointcut matches a particular join point 
		if and only if</emphasis>:
		</para>
		
		<orderedlist>
		    <listitem>They are of the same kind</listitem>
		    <listitem>The signature pattern (exactly) matches at least one 
		    signature of the join point</listitem>
		    <listitem>The modifiers pattern matches the modifiers of the
		    subject of the join point</listitem>
		</orderedlist>
        
        <para>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.</para>
        
    </sect1>
  
      <sect1 id="join-point-signatures">
        <title>Join Point Signatures</title>
        
        <para>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.</para>
        
        <informaltable>
        <tgroup cols="7">
            <thead>
                <row>
                    <entry>Join Point Kind</entry>
                    <entry>Return Type</entry>                
                    <entry>Declaring Type</entry>                
                    <entry>Id</entry>                
                    <entry>Parameter Types</entry>                
                    <entry>Field Type</entry>                
                    <entry>Exception Type</entry>                
                </row>
            </thead>
            <tbody>
                <row>
                    <entry>Method call</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Method execution</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Constructor call</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Constructor execution</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Field get</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Field set</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Pre-initialization</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Initialization</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Static initialization</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                    <entry></entry>
                    <entry></entry>
                </row>
                <row>
                    <entry>Handler</entry>
                    <entry></entry>
                    <entry></entry>
                    <entry></entry>
                    <entry></entry>
                    <entry></entry>
                    <entry>+</entry>
                </row>
                <row>
                    <entry>Advice execution</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry>+</entry>
                    <entry></entry>
                    <entry></entry>
                </row>
            </tbody>
        </tgroup>
        </informaltable>
        
        <para>Note that whilst an advice excetution join point has a
        signature comprising the declaring type of the advice and the
        advice parameter types, the <literal>adviceexecution</literal>
        pointcut designator does not support matching based on this
        signature.</para>
        
        <para>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.
        </para>
        
        <para>The following sections examine signatures for these join points 
        in more detail.</para>
        
        <sect2 id="method-call-join-point-signatures" xreflabel="method-call-join-point-signatures">
            <title>Method call join point signatures</title>

        <para>
          For a call join point where a call is made to a method
          <literal>m(parameter_types)</literal> on a target type <literal>T</literal> (where
          <literal>T</literal> is the static type of the target):
        </para>

		<programlisting><![CDATA[
		T t = new T(); 
		t.m("hello");  <= call join point occurs when this line is executed
		]]></programlisting>
        
        <para>
            Then the signature <literal>R(T) T.m(parameter_types)</literal> is a signature
            of the call join point, where <literal>R(T)</literal> is the return
            type of <literal>m</literal> in <literal>T</literal>, and 
            <literal>parameter_types</literal> are the parameter types of
            <literal>m</literal>. If <literal>T</literal> itself does not
            declare a definition of <literal>m(parameter_types)</literal>, then 
            <literal>R(T)</literal> is the return type in the definition of 
            <literal>m</literal> that <literal>T</literal> inherits. Given the
            call above, and the definition of <literal>T.m</literal>:                      
        </para>
        
        <programlisting><![CDATA[
        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 {} 
		
		]]></programlisting>
        
        <para>Then <literal>R' T.m(String)</literal> is a signature of the
        call join point for <literal>t.m("hello")</literal>.</para>
        
        <para>
            For each ancestor (super-type) <literal>A</literal> of <literal>T</literal>, 
            if <literal>m(parameter_types)</literal> is defined for that super-type, then
            <literal>R(A) A.m(parameter_types)</literal> is a signature of the call join
            point, where <literal>R(A)</literal> is the return type of <literal>
            m(parameter_types)</literal> as defined in <literal>A</literal>, or as inherited
            by <literal>A</literal> if <literal>A</literal> itself does not
            provide a definition of <literal>m(parameter_types)</literal>.            
        </para>
        
        <para>
            Continuing the example from above,we can deduce that
        </para>

        <programlisting><![CDATA[
        R' S.m(String)
        R  P.m(String)
        R  Q.m(String)
		]]></programlisting>
        
        <para>are all additional signatures for the call join point arising
        from the call <literal>t.m("hello")</literal>. Thus this call
        join point has four signatures in total. Every signature has the same
        id and parameter types, and a different declaring type.</para>
        
       </sect2>
      
      <sect2 id="method-execution-join-point-signatures" xreflabel="method-execution-join-point-signatures">
          <title>Method execution join point signatures</title>
          
          <para>Join point signatures for execution join points are defined
          in a similar manner to signatures for call join points. Given the
          hierarchy:
          </para>


        <programlisting><![CDATA[
        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) {...}
        }
		
		]]></programlisting>
        
        <para>Then the execution join point signatures arising as a result
        of the call to <literal>u.m("hello")</literal> are: </para>

        <programlisting><![CDATA[
        R' U.m(String)
        R' S.m(String)
        R  P.m(String)
        R  Q.m(String)
		]]></programlisting>

        <para>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 <literal>R' T.m(String)</literal>
        as <literal>T</literal> does not provide its own declaration of
        the method.</para>

      </sect2>

       <sect2 id="field-get-and-set-join-point-signatures" xreflabel="field-get-and-set-join-point-signatures">
            <title>Field get and set join point signatures</title>

        <para>
            For a field get join point where an access is made to a field
            <literal>f</literal> of type <literal>F</literal> 
            on a object with declared type <literal>T</literal>, then
            <literal>F T.f</literal> is a signature of the get join point.  
        </para>
        
        <para>
            If <literal>T</literal> does not directly declare a member
            <literal>f</literal>, then for each super type <literal>S</literal>
            of <literal>T</literal>, up to and including the most specific
            super type of <literal>T</literal> that does declare the member
            <literal>f</literal>, <literal>F S.f</literal> is a signature
            of the join point. For example, given the hierarchy:
        </para>

        <programlisting><![CDATA[        
        class P  {
          F f;        
        }
        
        class S extends P {
          F f;
        }
        
        class T extends S { }                
		]]></programlisting>
		
		<para>
		    Then the join point signatures for a field get join point of
		    the field <literal>f</literal> on an object with declared type
		    <literal>T</literal> are:
		</para>

        <programlisting><![CDATA[
        F S.f
        F T.f
		]]></programlisting>

        <para>The signatures for a field set join point are derived in an
            identical manner.</para>
            
       </sect2>
             
      </sect1>
      
      <sect1 id="join-point-modifiers">
          <title>Join Point Modifiers</title>
          
          <para>Every join point has a single set of modifiers - these include
          the standard Java modifiers such as <literal>public, private,
          static, abstract</literal> etc., any annotations, and the throws
          clauses of methods and constructors. These modifiers are the
          modifiers of the <emphasis>subject</emphasis> of the join point.</para>
          
          <para>
          The following table defines the join point subject for each kind
          of join point.
          </para>

             <informaltable>
           <tgroup cols="2">
               <thead>
                   <row>
                       <entry>Join Point Kind</entry>
                       <entry>Subject</entry>
                   </row>
               </thead>
               <tbody>
                   <row>
                       <entry>Method call</entry>
                       <entry>The method picked out by Java as
                       the static target of the method call.</entry>
                   </row>
                   <row>
                       <entry>Method execution</entry>
                       <entry>The method that is executing.</entry>
                   </row>
                   <row>
                       <entry>Constructor call</entry>
                       <entry>The constructor being called.</entry>
                   </row>
                   <row>
                       <entry>Constructor execution</entry>
                       <entry>The constructor executing.</entry>
                   </row>
                   <row>
                       <entry>Field get</entry>
                       <entry>The field being accessed.</entry>
                   </row>
                   <row>
                       <entry>Field set</entry>
                       <entry>The field being set.</entry>
                   </row>
                   <row>
                       <entry>Pre-initialization</entry>
                       <entry>The first constructor executing in
                       this constructor chain.</entry>
                   </row>
                   <row>
                       <entry>Initialization</entry>
                       <entry>The first constructor executing in
                       this constructor chain.</entry>
                   </row>
                   <row>
                       <entry>Static initialization</entry>
                       <entry>The type being initialized.</entry>
                   </row>
                   <row>
                       <entry>Handler</entry>
                       <entry>The declared type of the
                       exception being handled.</entry>
                   </row>
                   <row>
                       <entry>Advice execution</entry>
                       <entry>The advice being executed.</entry>
                   </row>
               </tbody>
           </tgroup>
          </informaltable>          

             <para>For example, given the following types</para>

        <programlisting><![CDATA[
        public class X {        
          @Foo
          protected void doIt() {...} 
        }
        
        public class Y extends X {        
          public void doIt() {...}        
        }
		]]></programlisting>
          
         <para>Then the modifiers for a call to <literal>(Y y) y.doIt()</literal>
         are simply <literal>{public}</literal>. The modifiers for a call to
         <literal>(X x) x.doIt()</literal> are <literal>{@Foo,protected}</literal>.
         </para>
          
      </sect1>
      
      <sect1 id="join-point-matching-summary">
          <title>Summary of Join Point Matching</title>

		<para>
		A join point has potentially multiple signatures, but only one set of
		modifiers. <emphasis>A kinded primitive pointcut matches a particular join point 
		if and only if</emphasis>:
		</para>
		
		<orderedlist>
		    <listitem>They are of the same kind</listitem>
		    <listitem>The signature pattern (exactly) matches at least one 
		    signature of the join point</listitem>
		    <listitem>The modifiers pattern matches the modifiers of the
		    subject of the join point</listitem>
		</orderedlist>

        <para>Given the hierarchy</para>

        <programlisting><![CDATA[
        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 {} 
		
		]]></programlisting>

        <para>and the program fragment:</para>
        
        <programlisting><![CDATA[
        P p = new P();
        S s = new S();
        T t = new T();
        ...
        p.m("hello");
        s.m("hello");
        t.m("hello");
		]]></programlisting>
        
        <para>
        The the pointcut <literal>call(@Foo R P.m(String))</literal> matches the
        call <literal>p.m("hello")</literal> since both the signature and the 
        modifiers match. It does not match the call <literal>s.m("hello")</literal>
        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.
        </para>

        <para>The pointcut <literal>call(R' m(String))</literal> matches the
        calls <literal>t.m("hello")</literal> and <literal>s.m("hello")</literal>.
        It does not match the call <literal>p.m("hello")</literal> since the
        signature pattern does not match any signature for the call join point
        of m in P.</para>
      </sect1>
  
</chapter>