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
|
<appendix id="implementation" xreflabel="Implementation Notes">
<title>Implementation Notes</title>
<sect1>
<title>Compiler Notes</title>
<para>
The initial implementations of AspectJ have all been
compiler-based implementations. Certain elements of AspectJ's
semantics are difficult to implement without making modifications
to the virtual machine, which a compiler-based implementation
cannot do. One way to deal with this problem would be to specify
only the behavior that is easiest to implement. We have chosen a
somewhat different approach, which is to specify an ideal language
semantics, as well as a clearly defined way in which
implementations are allowed to deviate from that semantics. This
makes it possible to develop conforming AspectJ implementations
today, while still making it clear what later, and presumably
better, implementations should do tomorrow.
</para>
<para>
According to the AspectJ language semantics, the declaration
</para>
<programlisting><![CDATA[
before(): get(int Point.x) { System.out.println("got x"); }
]]></programlisting>
<para>
should advise all accesses of a field of type int and name x from
instances of type (or subtype of) Point. It should do this
regardless of whether all the source code performing the access
was available at the time the aspect containing this advice was
compiled, whether changes were made later, etc.
</para>
<para>
But AspectJ implementations are permitted to deviate from this in
a well-defined way -- they are permitted to advise only accesses
in <emphasis>code the implementation controls</emphasis>. Each
implementation is free within certain bounds to provide its own
definition of what it means to control code.
</para>
<para>
In the current AspectJ compiler, ajc, control of the code means
having bytecode for any aspects and all the code they should
affect available during the compile. This means that if some class
Client contains code with the expression <literal>new
Point().x</literal> (which results in a field get join point at
runtime), the current AspectJ compiler will fail to advise that
access unless Client.java or Client.class is compiled as well. It
also means that join points associated with code in native methods
(including their execution join points) cannot be advised.
</para>
<para>
Different join points have different requirements. Method and
constructor call join points can be advised only if ajc controls
the bytecode for the caller. Field reference or assignment join
points can be advised only if ajc controls the bytecode for the
"caller", the code actually making the reference or assignment.
Initialization join points can be advised only if ajc controls the
bytecode of the type being initialized, and execution join points
can be advised only if ajc controls the bytecode for the method or
constructor body in question.
The end of an exception handler is underdetermined in bytecode,
so ajc will not implement after or around advice on handler join
points.
Similarly, ajc cannot implement around advice on initialization
or preinitialization join points.
In cases where ajc cannot implement advice, it will emit a
compile-time error noting this as a compiler limitation.
</para>
<para>
Aspects that are defined <literal>perthis</literal> or
<literal>pertarget</literal> also have restrictions based on
control of the code. In particular, at a join point where the
bytecode for the currently executing object is not available, an
aspect defined <literal>perthis</literal> of that join point will
not be associated. So aspects defined
<literal>perthis(Object)</literal> will not create aspect
instances for every object unless <literal>Object</literal>is part
of the compile. Similar restrictions apply to
<literal>pertarget</literal> aspects.
</para>
<para>
Inter-type declarations such as <literal>declare parents</literal>
also have restrictions based on control of the code. If the
bytecode for the target of an inter-type declaration is not
available, then the inter-type declaration is not made on that
target. So, <literal>declare parents : String implements
MyInterface</literal> will not work for
<literal>java.lang.String</literal> unless
<literal>java.lang.String</literal> is part of the compile.
</para>
<para>
Other AspectJ implementations, indeed, future versions of ajc, may
define <emphasis>code the implementation controls</emphasis> more
liberally or restrictively.
</para>
<para>
The important thing to remember is that core concepts of AspectJ,
such as the join point, are unchanged, regardless of which
implementation is used. During your development, you will have to
be aware of the limitations of the ajc compiler you're using, but
these limitations should not drive the design of your aspects.
</para>
</sect1>
<sect1>
<title>Bytecode Notes</title>
<sect2>
<title>The .class expression and String +</title>
<para> The java language form <literal>Foo.class</literal> is
implemented in bytecode with a call to
<literal>Class.forName</literal> guarded by an exception
handler catching a <literal>ClassNotFoundException</literal>.
</para>
<para> The java language + operator, when applied to String
arguments, is implemented in bytecode by calls to
<literal>StringBuffer.append</literal>.
</para>
<para> In both of these cases, the current AspectJ compiler
operates on the bytecode implementation of these language
features; in short, it operates on what is really happening rather
than what was written in source code. This means that there may
be call join points to <literal>Class.forName</literal> or
<literal>StringBuffer.append</literal> from programs that do not,
at first glance, appear to contain such calls:
</para>
<programlisting><![CDATA[
class Test {
void main(String[] args) {
System.out.println(Test.class); // calls Class.forName
System.out.println(args[0] + args[1]); // calls StringBuffer.append
}
}
]]></programlisting>
<para>In short, the join point model of the current AspectJ
compiler considers these as valid join points.
</para>
</sect2>
<sect2>
<title>The Handler join point</title>
<para>The end of exception handlers cannot reliably be found in Java
bytecode. Instead of removing the handler join point entirely, the
current AspectJ compiler restricts what can be done with the handler
join point:
</para>
<itemizedlist>
<listitem>After and around advice cannot apply to handler
join points.</listitem>
<listitem>The control flow of a handler join point cannot be
detected. </listitem>
</itemizedlist>
<para>
The first of these is relatively straightforward. If any piece of
after advice (returning, throwing, or "finally") would normally
apply to a handler join point, it will not in code output by the
current AspectJ compiler. A compiler warning is generated whenever
this is detected to be the case. Before advice is allowed.
</para>
<para> The second is that the control flow of a handler join point
is not picked out. For example, the following pointcut
</para>
<programlisting><![CDATA[
cflow(call(void foo()) || handler(java.io.IOException))
]]></programlisting>
<para> will capture all join points in the control flow of a call to
<literal>void foo()</literal>, but it will <emphasis>not</emphasis>
capture those in the control flow of an
<literal>IOException</literal> handler. It is equivalent to
<literal>cflow(call(void foo()))</literal>. In general,
<literal>cflow(handler(<replaceable>Type</replaceable>))</literal>
will pick out no join points.
</para>
<para> This does not restrict programs from placing before advice on
handlers inside <emphasis>other</emphasis> control flows. This
advice, for example, is perfectly fine:
</para>
<programlisting><![CDATA[
before(): handler(java.io.IOException) && cflow(void parse()) {
System.out.println("about to handle an exception while parsing");
}
]]></programlisting>
<para>
A source-code implementation of AspectJ (such as AspectJ 1.0.6) is
able to detect the endpoint of a handler join point, and as such
will likely have fewer such restrictions.
</para>
</sect2>
</sect1>
</appendix>
|
