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
|
<chapter id="covariance" xreflabel="Covariance">
<title>Covariance</title>
<sect1 id="covariance-inJava5">
<title>Covariance in Java 5</title>
<para>
Java 5 (and hence AspectJ 1.5) allows you to narrow the return type
in an overriding method. For example:
</para>
<programlisting><![CDATA[
class A {
public A whoAreYou() {...}
}
class B extends A {
// override A.whoAreYou *and* narrow the return type.
public B whoAreYou() {...}
}
]]></programlisting>
</sect1>
<sect1>
<title>Covariant methods and Join Point matching</title>
<para>The join point matching rules for <literal>call</literal>
and <literal>execution</literal> pointcut designators are extended
to match against covariant methods.</para>
<para>
Given the classes <literal>A</literal> and <literal>B</literal>
as defined in the previous section, and the program fragment
</para>
<programlisting><![CDATA[
A a = new A();
B b = new B();
a.whoAreYou();
b.whoAreYou();
]]></programlisting>
<para>Then the call and execution join points for <literal>whoAreYou</literal>
are matched as follows:</para>
<variablelist>
<varlistentry>
<term>call(* whoAreYou())</term>
<listitem>
<para>Matches both calls, (since it places no constraint on the
return type of the join point signature).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(* A.whoAreYou())</term>
<listitem>
<para>Matches both calls, (since the original declaring type
of <literal>whoAreYou</literal> is <literal>A</literal>).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(A whoAreYou())</term>
<listitem>
<para>Matches both calls, (since the signature of
<literal>whoAreYou</literal>) in the original declaring type
has a return type of <literal>A</literal>).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(A B.whoAreYou())</term>
<listitem>
<para>Does not match anything - the signature of <literal>whoAreYou</literal>
as overriden in <literal>B</literal> has a return type of
<literal>B</literal>, not <literal>A</literal>. A lint warning is
given for the call <literal>a.whoAreYou()</literal> ("does not match
because declaring type is A, if match required use target(B)").
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(A+ B.whoAreYou())</term>
<listitem>
<para>Matches the call to <literal>b.whoAreYou()</literal> since
the return type <literal>B</literal> in the method signature
is matched by the type pattern <literal>A+</literal>. A lint warning is
given for the call <literal>a.whoAreYou()</literal> ("does not match
because declaring type is A, if match required use target(B)").
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(B A.whoAreYou())</term>
<listitem>
<para>Does not match anything - there is no method declared in
<literal>A</literal> with a return type of <literal>B</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(B whoAreYou())</term>
<listitem>
<para>Matches the call to <literal>b.whoAreYou()</literal> only.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>call(B B.whoAreYou())</term>
<listitem>
<para>Matches the call to <literal>b.whoAreYou()</literal> only.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>The rule for signature matching at call and execution join points
is unchanged from AspectJ 1.2: a call or execution pointcut matches if
the signature pattern matches at least one of the signatures of the
join point, and if the most-specific matched signature is also matched
by any modifier pattern or annotation pattern that may be present.</para>
<para>For a call or execution join point, the signatures of a join point
for the call or execution of a method <literal>Rtype T.m(params)</literal>
are determined as follows:</para>
<itemizedlist>
<listitem>
If <literal>m(params)</literal> is defined in <literal>T</literal>,
then the signature of <literal>m(params)</literal> in <literal>T</literal> is
a signature of the join point: <literal>Rtype T.m(params)</literal>.
If <literal>T</literal> does not
provide its own definition of <literal>m</literal>, then the signature
<literal>Rtype' T.m(params)</literal>
is a signature of the join point, where <literal>Rtype'</literal> is the return type of
the definition of <literal>m</literal> inherited by <literal>T</literal>.
</listitem>
<listitem>
For each super-type <literal>S</literal> of <literal>T</literal> that is a valid receiver
for a call to <literal>m</literal>, then the signature of <literal>m(params)</literal> in
<literal>S</literal> is a signature
of the join point: <literal>Rtype S.m(params)</literal>.
If <literal>S</literal> does not provide its
own definition of <literal>m</literal>, then the signature
<literal>Rtype' S.m(params)</literal> is a
signature of the join point, where <literal>Rtype'</literal> is the return type of the
definition of <literal>m</literal> inherited by <literal>S</literal>.
</listitem>
</itemizedlist>
<para>A call to <literal>b.whoAreYou()</literal> has the join point signatures
</para>
<itemizedlist>
<listitem>B B.whoAreYou()</listitem>
<listitem>A A.whoAreYou()</listitem>
</itemizedlist>
<para>Following the rule given, it is easy to see why for example
<literal>call(B A.whoAreYou())</literal> does not match anything as
this pattern matches neither of the signatures at the join point. In
contrast, the pointcut expression <literal>call(A+ B.whoAreYou())</literal>
does match the call to <literal>b.whoAreYou()</literal> because it matches
the second of the signatures at the join point.</para>
</sect1>
</chapter>
|
