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
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 1.1 Readme</title>
<style type="text/css">
<!--
P { margin-left: 20px; }
PRE { margin-left: 20px; }
LI { margin-left: 20px; }
H4 { margin-left: 20px; }
H3 { margin-left: 10px; }
-->
</style>
</head>
<body>
<div align="right"><small>
© Copyright 2002 Palo Alto Research Center, Incorporated,
2003 Contributors.
All rights reserved.
</small></div>
<h1>AspectJ 1.1 Readme</h1>
<p> This is the initial release of AspectJ 1.1. It includes a small
number of new language features as well as major improvements to the
functionality of the tools. </p>
<p>
This document describes the differences between
AspectJ versions 1.1 and 1.0.6.
Users new to AspectJ need only read
the <a href="progguide/index.html">AspectJ Programming Guide</a>
since it describes the 1.1 language.
Users familiar with AspectJ 1.0 may find this document
a quicker way to learn what changed in the language
and tools, and should use it as a guide for porting
programs from 1.0 to 1.1.
</p>
<p>This document first summarizes changes from the 1.0 release in
</p>
<ul>
<li><a href="#language">the language</a>,</li>
<li><a href="#compiler">the compiler</a>,</li>
<li><a href="#tools">the support tools</a>,</li>
<li><a href="#runtime">the runtime</a>,</li>
<li><a href="#devenv">the development environment support</a>,</li>
<li><a href="#sources">the sources</a>, and</li>
<li><a href="#distribution">the distribution</a>,</li>
</ul>
<p> then <a href="#details">details</a> some of the language
and compiler changes,
and finally points readers to the bug database for any
<a href="#knownLimitations">known limitations</a>.
</p>
<!-- ============================== -->
<hr>
<h2><a name="language">The Language</a></h2>
<p> AspectJ 1.1 is a slightly different language than AspectJ 1.0.
In all but a few cases, programs written in AspectJ 1.0 should
compile correctly in AspectJ 1.1. In many cases, there are
new or preferred forms in AspectJ 1.1. However, some AspectJ 1.0
features have changed in 1.1, so some 1.0 programs
will not compile or will run differently in 1.1.
The corresponding features are marked below as compile-time
or run-time incompatible (<em>CTI</em> or <em>RTI</em>, respectively).
When the language change involves a move in the static shadow effective
at run-time but also apparent at compile-time (e.g., in declare
error or warning statements), it is marked <em>CRTI</em>.
Programs using run-time incompatible forms should be verified that
they are behaving as expected in 1.1.
</p>
<p>
Most changes to the language are additions to expressibility
requested by our users:
</p>
<ul>
<li><a href="#THROWS_PATTERN">Matching based on throws</a>: You can
now make finer discriminations between methods based on declared
exceptions. </li>
<li><a href="#NEW_PCDS">New kinded pointcut designators</a>: Now
every kind of join point has a corresponding kinded pointcut
designator. </li>
</ul>
<p> Some are have different behavior in edge cases but offer
improved power and clarity: </p>
<ul>
<li><a href="#ASPECT_PRECEDENCE">New aspect precedence form</a>:
AspectJ 1.1 has a new declare form, <code>declare
precedence</code>, that replaces the "dominates"
clause on aspects. (<em>CTI</em>) </li>
<li>The order of <a href="#SUPER_IFACE_INITS">initialization join
points for super-interfaces</a> has been clarified. (<em>RTI</em>) </li>
</ul>
<p> But in order to support weaving into bytecode effectively,
several incompatible changes had to be made to the language: </p>
<ul>
<li>A class's default constructor may
<a href="#DEFAULT_CONSTRUCTOR_CONFLICT">conflict</a> with an
inter-type constructor. (<em>CTI</em>) </li>
<li><a href="#NO_CALLEE_SIDE_CALL">No callee-side call join
points</a>: The AspectJ 1.1 compiler does not expose call join
points unless it is given the calling code. (<em>CRTI</em>) </li>
<li><a href="#SINGLE_INTERCLASS_TARGET">One target for intertype
declarations</a>. (<em>CTI</em>) </li>
<li><a href="#UNAVAILABLE_JOIN_POINTS">No initializer execution join
points</a>. (<em>RTI</em>)</li>
<li><a href="#AFTER_HANDLER">No after or around advice on handler
join points</a>. (<em>CTI</em>) </li>
<li><a href="#CONSTRUCTOR_EXECUTION_IS_BIGGER">Initializers run
inside constructor execution join points</a>. (<em>RTI</em>)</li>
<li><a href="#INTER_TYPE_FIELD_INITIALIZERS">inter-type field
initializers</a> run before class-local field initializers. (<em>RTI</em>) </li>
<li><a href="#WITHIN_MEMBER_TYPES">Small limitations of the within
pointcut.</a> (<em>CRTI</em>)</li>
<li><a href="#WITHIN_CODE">Small limitations of the withincode
pointcut.</a> (<em>CRTI</em>)</li>
<li><a href="#INSTANCEOF_ON_WILD">Can't do instanceof matching on
type patterns with wildcards</a>. (<em>CTI</em>) </li>
<li><a href="#NO_SOURCE_COLUMN">SourceLocation.getColumn() is
deprecated and will always return 0</a>. (<em>RTI</em>) </li>
<li>The interaction between aspect instantiation and advice has been
<a href="#ASPECT_INSTANTIATION_AND_ADVICE">clarified</a>. (<em>RTI</em>) </li>
<li><a href="#STRINGBUFFER">The String + operator is now correctly advised</a>.
(<em>CRTI</em>) </li>
</ul>
<p><a name="NEW_LIMITATIONS">There</a> are a couple of language
limitations for things that are rarely used that make the
implementation simpler, so we have restricted the language accordingly.
</p>
<ul>
<li><a href="#VOID_FIELD_SET">Field set join points now have a
<code>void</code> return type.</a> This will require
porting of code that uses the <code>set</code> PCD in conjunction
with after-returning or around advice. (<em>CTI</em>) <p></p></li>
<li>'declare soft: TYPE: POINTCUT;' - AspectJ 1.1 only
accepts TYPE rather than a TYPE_PATTERN.
This limitation makes declare soft
much easier to implement efficiently. (<em>CTI</em>) <p></p></li>
<li>Inter-type field declarations only allow a single field per
line, i.e. this is now illegal 'int C.field1, D.field2;' This must
instead be, 'int C.field1; int D.field2;' (<em>CTI</em>) <p></p></li>
<li>We did not implement the handling of more than one
<code>..</code> wildcard in args PCD's (rarely encountered in the
wild) because we didn't have the time. This might be available
in later releases if there is significant outcry. (<em>CTI</em>) </li>
</ul>
<p>We did not implement the long-awaited <a href="#PER_TYPE">new
pertype aspect specifier</a> in this release, but it may well
be in a future release.</p>
<!-- ============================== -->
<hr>
<h2><a name="compiler">The Compiler</a></h2>
<p> The compiler for AspectJ 1.1 is different than the compiler for
AspectJ 1.0. While this document describes the differences in the
compiler, it's worthwhile noting that much effort has been made to
make sure that the interface to ajc 1.1 is, as much as possible, the
same as the interface to ajc 1.0. There are two important changes
under the hood, however. </p>
<p> First, the 1.1 compiler is implemented on top of the
open-source Eclipse compiler. This has two benefits: It allows us
to concentrate on the AspectJ extensions to Java and let the Eclipse
team worry about making sure the Java edge cases work, and it allows
us to piggyback on Eclipse's already mature incremental compilation
facilities. </p>
<p> Second, ajc now cleanly delineates compilation of source code
from assembly (or "weaving") of bytecode. The compiler still
accepts source code, but internally it transforms it into bytecode
format before weaving. </p>
<p> This new architecture, and other changes to the compiler, allows
us to implement some features that were defined in the AspectJ 1.0
language but not implementable in the 1.1 compiler. It also makes
some new features available: </p>
<ul>
<li><a href="#SOURCEROOT">The -sourceroots option</a>
takes one or more directories, and indicates that all the source
files in those directories should be passed to the compiler. </li>
<li><a href="#BYTECODE_WEAVING">The -injars option</a>
takes one or more jar files, and indicates that all the classfiles
in the jar files should be woven into. </li>
<li><a href="#BINARY_ASPECTS">The -aspectpath option</a>
takes one or more jar files, and weaves any aspects in .class form
into the sources.</li>
<li><a href="#OUTJAR">The -outjar option</a> indicates
that the result classfiles of compiling and weaving should be placed
in the specified jar file. </li>
<li><a href="#XLINT">The -Xlint option</a> allows control over
warnings.</li>
<li><a href="#OTHER_X_OPTIONS">Various -X options</a> changed.</li>
<li><a href="#INCREMENTAL">The -incremental option</a> tells the
AspectJ 1.1 compiler to recompile only as necessary. </li>
</ul>
<p> Some other features we wanted to support for 1.1, but did not make
it into this release: </p>
<ul>
<li><a href="#ERROR_MESSAGES">Error messages will sometimes be scary</a></li>
<li><a href="#MESSAGE_CONTEXT">Source code context is not shown
for errors and warnings detected during bytecode weaving</a></li>
</ul>
<p> But some features of the 1.0 compiler are not supported in the
1.1 compiler: </p>
<ul>
<li><a href="#NO_SOURCE">The source-related options</a> -preprocess,
-usejavac, -nocomment and -workingdir</li>
<li><a href="#NO_STRICT_LENIENT">The -strict and -lenient options</a>
</li>
<li><a href="#NO_PORTING">The -porting option</a></li>
<li><a href="#13_REQUIRED">J2SE 1.2 is not supported;
J2SE 1.3 or later is required.</a></li>
</ul>
<p> A short description of the options ajc accepts is available with
"<code>ajc -help</code>".
Longer descriptions are available in the
<a href="devguide/ajc-ref.html">Development Environment Guide
section on ajc</a>. </p>
<p> </p>
<p> Some changes to the implementation are almost entirely
internal:
</p>
<ul>
<li>The behavior of the compiler in
<a href="#TARGET_TYPES_MADE_PUBLIC">lifting the visibility</a> of
the target types of some declares and pointcuts to public has been
clarified. </li>
</ul>
<p> Also, it is worth noting that because AspectJ now works on bytecode,
it is somewhat sensitive to how different compilers generate
bytecode, especially when compiling with and without <a
href="#ONE_FOUR_METHOD_SIGNATURES">the -1.4 flag</a>. </p>
<!-- ============================== -->
<hr>
<h2><a name="tools">Support Tools</a></h2>
<p>This release includes an Ant task for old-style 1.0 build
scripts, a new task for all the new compiler options, and a
CompilerAdapter to support running <code>ajc</code> with the Javac
task by setting the <code>build.compiler</code> property.
The new task can automatically copy input resources to output
and work in incremental mode using a "tag" file.
</p>
<p>This release does not include <code>ajdoc</code>, the
documentation tool for AspectJ sources.
Ajdoc is deeply dependent on the
abstract syntax tree classes from the old compiler, so it needs a
bottom-up rewrite. We think it best to use this opportunity to
implement more general API's for publishing and rendering static
structure. Because those API's are last to settle in the new
architecture, and because the compiler itself is a higher priority,
we are delaying work on ajdoc until after the 1.1 release.</p>
<p>AspectJ 1.1 will not include <tt>ajdb</tt>, the AspectJ
stand-alone debugger. It is no longer necessary for two reasons.
First, the -XnoInline flag will tell the compiler to generate
code without inlining that should work correctly with any Java
debugger. For code generated with inlining enabled, more
third-party debuggers are starting to work according to JSR 45,
"Debugging support for other languages," which is supported by
AspectJ 1.0. We aim to support JSR-45 in AspectJ 1.1, but
support will not be in the initial release. Consider using
the -XnoInline flag until support is available.</p>
<!-- ============================== -->
<hr>
<h2><a name="runtime">The Runtime Library</a></h2>
<p>This release has minor additions to the runtime library classes.
As with any release, you should compile and run with the runtime
library that came with your compiler, and you may run with
a later version of the library without recompiling your code.</p>
<p> In one instance, however, runtime classes behave differently this release.
Because the AspectJ 1.1 compiler does its weaving through
bytecode, column numbers of source locations are not available.
Therefore, <code>thisJoinPoint.getSourceLocation().getColumn()</code>
is deprecated and will always return 0. </p>
<!-- ============================== -->
<hr>
<h2><a name="devenv">The AJDE Tools</a></h2>
<p> The AspectJ Browser supports incremental compilation and running
programs. AJDE for JBuilder, AJDE for NetBeans, and AJDE for Emacs
are now independent SourceForge projects (to keep their licenses).
They use the batch-build mode of the new compiler.
</p>
<!-- ============================== -->
<hr>
<h2><a name="sources">The Sources and the Licenses</a></h2>
<p>The AspectJ tools sources are available under the
<a href="https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt">Eclipse Public License v 2.0</a>
in the Git repository at
<a href="http://eclipse.org/aspectj">http://eclipse.org/aspectj</a>.
For more information, see the FAQ entry on
<a href="faq.html#q:buildingsource">building sources</a>.
</p>
<!-- ============================== -->
<hr>
<h2><a name="distribution">The AspectJ distribution</a></h2>
<p> AspectJ 1.0 had many distributions - for the tools,
the documentation, each IDE support package,
their respective sources, and the Ant tasks -
because they came under different licenses.
All of AspectJ 1.1 is licensed under the CPL 1.0,
so the tools, Ant tasks, and documentation are all
in one distribution available from
<a href="http://eclipse.org/aspectj">
http://eclipse.org/aspectj</a>.
To retain their MPL 1.1 license,
Ajde for
<a href="http://aspectj4emacs.sourceforge.net/">Emacs</a>,
<a href="http://aspectj4netbean.sourceforge.net/">NetBeans</a> and
<a href="http://aspectj4jbuildr.sourceforge.net/">JBuilder</a>
are now independent SourceForge projects. </p>
</p>
<!-- ============================== -->
<hr>
<hr>
<h2><a name="details">Details</a> of some language and compiler changes</h2>
<h3><a name="ASPECT_INSTANTIATION_AND_ADVICE">Aspect Instantiation
and Advice</a></h3>
<p> In AspectJ 1.0.6, we made an effort to hide some complications
with Aspect instantiation from the user. In particular, the
following code compiled and ran:
</p>
<PRE>
public class Client
{
public static void main(String[] args) {
Client c = new Client();
}
}
aspect Watchcall {
pointcut myConstructor(): execution(new(..));
before(): myConstructor() {
System.err.println("Entering Constructor");
}
}
</PRE>
<p> But there's a conceptual problem with this code: The before
advice should run before the execution of all constructors in the
system. It must run in the context of an instance of the
Watchcall aspect. The only way to get such an instance is to have
Watchcall's default constructor execute. But before that
executes, we need to run the before advice...</p>
<p> AspectJ 1.0.6 hid this circularity through the ad-hoc
mechanism of preventing an aspect's advice from matching join
points that were within the aspect's definition, and occurred
before the aspect was initialized. But even in AspectJ 1.0.6,
this circularity could be exposed:
</p>
<PRE>
public class Client
{
public static int foo() { return 3; }
public static void main(String[] args) {
Client c = new Client();
}
}
aspect Watchcall {
int i = Client.foo();
pointcut myConstructor():
execution(new(..)) || execution(int foo());
before(): myConstructor() {
System.err.println("Entering Constructor");
}
}
</PRE>
<p>This program would throw a NullPointerException when run, since
Client.foo() was called before the Watchcall instance could be
instantiated. </p>
<p> In AspectJ 1.1, we have decided that half-hiding the problem
just leads to trouble, and so we are no longer silently hiding
some join points before aspect initialization. However, we have
provided a better exception than a NullPointerException for this
case. In AspectJ 1.1, both of the above programs will throw
org.aspectj.lang.NoAspectBoundException.
</p>
<h3><a name="THROWS_PATTERN">Matching based on throws</a></h3>
<p> Type patterns may now be used to pick out methods and
constructors based on their throws clauses. This allows the
following two kinds of extremely wildcarded pointcuts: </p>
<pre> pointcut throwsMathlike():
// each call to a method with a throws clause containing at least
// one exception with "Math" in its name.
call(* *(..) throws *..*Math*);
pointcut doesNotThrowMathlike():
// each call to a method with a throws clause containing no
// exceptions with "Math" in its name.
call(* *(..) throws !*..*Math*);
</pre>
<p> The longwinded rules are that a method or constructor pattern
can have a "throws clause pattern". Throws clause patterns look
like: </p>
<pre> ThrowsClausePattern:
ThrowsClausePatternItem ("," ThrowsClausePatternItem)*
ThrowsClausePatternItem:
["!"] TypeNamePattern
</pre>
<p> A ThrowsClausePattern matches the ThrowsClause of any code
member signature. To match, each ThrowsClausePatternItem must
match the throws clause of the member in question. If any item
doesn't match, then the whole pattern doesn't match. This rule is
unchanged from AspectJ 1.0. </p>
<p> If a ThrowsClausePatternItem begins with "!", then it matches
a particular throws clause if and only if <em>none</em> of the
types named in the throws clause is matched by the
TypeNamePattern. </p>
<p> If a ThrowsClausePatternItem does not begin with "!", then it
matches a throws clause if and only if <em>any</em> of the types
named in the throws clause is matched by the TypeNamePattern.</p>
<p> These rules are completely backwards compatible with
AspectJ 1.0. The rule for "!" matching has one potentially
surprising property, in that the two PCD's shown below will have
different matching rules. </p>
<pre> [1] call(* *(..) throws !IOException)
[2] call(* *(..) throws (!IOException))
void m() throws RuntimeException, IOException {}
</pre>
<p> [1] will NOT match the method m(), because method m's throws
clause declares that it throws IOException. [2] WILL match the
method m(), because method m's throws clause declares the it
throws some exception which does not match IOException,
i.e. RuntimeException. </p>
<h3><a name="NEW_PCDS">New kinded pointcut designators</a></h3>
<p> AspectJ 1.0 does not provide kinded pointcut designators for
two (rarely used) join points: preinitialization (the code that
runs before a super constructor call is made) and advice
execution. AspectJ 1.1 does not change the meaning of the join
points, but provides two new pointcut designators to pick out
these join points, thus making join points and pointcut
designators more parallel. </p>
<p> <code>adviceexectuion()</code> will pick out advice execution
join points. You will usually want to use <code>adviceexecution()
&& within(Aspect)</code> to restrict it to only those pieces of
advice defined in a particular aspect. <br>
<code>preinitialization(<var>ConstructorPattern</var>)</code> will
pick out pre-initialization join points where the initialization
process is entered through
<code><var>ConstructorPattern</var></code>. </p>
<h3><a name="PER_TYPE">New pertype aspect specifier</a> (not in 1.1)</h3>
<p>We strongly considered adding a pertype aspect kind to 1.1.
This is somewhat motivated by the new
<a href="#SINGLE_INTERCLASS_TARGET">restrictions on inter-type
declarations<a>. This is also motivated by many previous request
to support a common logging idiom. Here's what pertype would look
like:</p>
<pre> /** One instance of this aspect will be created for each class,
* interface or aspect in the com.bigboxco packages.
*/
aspect Logger pertype(com.bigboxco..*) {
/* This field holds a logger for the class. */
Log log;
/* This advice will run for every public execution defined by
* a type for which a Logger aspect has been created, i.e.
* any type in com.bigboxco..*
*/
before(): execution(public * *(..)) {
log.enterMethod(thisJoinPoint.getSignature().getName());
}
/* We can use a special constructor to initialize the log field */
public Logger(Class myType) {
this.log = new Log(myType);
}
}
/** External code could use aspectOf to get at the log, i.e. */
Log l = Logger.aspectOf(com.bigboxco.Foo.class).log;
</pre>
<p>The one open question that we see is how this should interact
with inner types. If a pertype aspect is created for an outer
type should advice in that aspect run for join points in inner
types? That is the behavior of the most common uses of this
idiom. </p>
<p> In any case, this feature will not be in AspectJ 1.1.
</p>
<h3><a name="SINGLE_INTERCLASS_TARGET">One target for intertype
declarations</a></h3>
<p> Intertype declarations (once called "introductions") in
AspectJ 1.1 can only have one target type. So the following code
intended to declare that there is a void doStuff() method on all
subtypes of Target is not legal AspectJ 1.1 code.
</p>
<pre> aspect A {
public void Target+.doStuff() { ... }
}
</pre>
<p> The functionality of "multi-intertype declarations" can be
recovered by using a helper interface.
</p>
<pre> aspect A {
private interface MyTarget {}
declare parents: Target+ implements MyTarget;
public void MyTarget.doStuff() { ... }
}
</pre>
<p> We believe this is better style in AspectJ 1.0 as well, as it
makes clear the static type of "this" inside the method body.
</p>
<p> The one piece of functionality that can not be easily
recovered is the ability to add static fields to many classes. We
believe that the <a href="#PER_TYPE">pertype proposal</a> provides
this functionality in a much more usable form.</p>
<h3><a name="UNAVAILABLE_JOIN_POINTS">No initializer execution join
points</a></h3>
<p> AspectJ 1.1 does not consider initializer execution a
principled join point. The collection of initializer code (the
code that sets fields with initializers and the code in non-static
initializer blocks) is something that makes sense only in Java
source code, not in Java bytecode. </p>
<h3><a name="AFTER_HANDLER"></a>No after or around advice on handler
join points</h3>
<p> The end of an exception handler is underdetermined in bytecode,
so ajc will not implement after or around advice on handler join
points, instead signaling a compile-time error.</p>
<h3><a name="CONSTRUCTOR_EXECUTION_IS_BIGGER">Initializers run
inside constructor execution join points</a></h3>
<p> The code generated by the initializers in Java source code now
runs inside of constructor execution join points. This changes
how before advice runs on constructor execution join points.
Consider: </p>
<pre> class C {
C() { }
String id = "identifier"; // this assignment
// has to happen sometime
}
aspect A {
before(C c) this(c) && execution(C.new()) {
System.out.println(c.id.length());
}
}
</pre>
<p> In AspectJ 1.0, this will print "10", since id is assigned its
initial value prior to the before advice's execution. However, in
AspectJ 1.1, this will throw a NullPointerExcception, since "id"
does not have a value prior to the before advice's execution.
</p>
<p> Note that the various flavors of after returning advice are
unchanged in this respect in AspectJ 1.1. Also note that this
only matters for the execution of constructors that call a
super-constructor. Execution of constructors that call a
this-constructor are the same in AspectJ 1.1 as in AspectJ 1.0.
</p>
<p> We believe this difference should be minimal to real programs,
since programmers using before advice on constructor execution
must always assume incomplete object initialization, since the
constructor has not yet run. </p>
<h3><a name="INTER_TYPE_FIELD_INITIALIZERS">Inter-type field initializers</a></h3>
<p> The initializer, if any, of an inter-type field definition runs
before the class-local initializers of its target class. </p>
<p> In AspectJ 1.0.6, such an initializer would run after the
initializers of a class but before the execution of any of its
constructor bodies. As already discussed in the sections about
<a href="#UNAVAILABLE_JOIN_POINTS">initializer execution join
points</a> and <a href="#CONSTRUCTOR_EXECUTION_IS_BIGGER">constructor
execution</a>, the point in code between the initializers of a class
and its constructor body is not principled in bytecode. So we had a
choice of running the initializer of an inter-type field definition at
the beginning of initialization (i.e., before initializers from
the target class) or at the end (i.e., just before its called
constructor exits). We chose the former, having this pattern in mind:
</p>
<PRE>
int C.methodCount = 0;
before(C c): this(c) && execution(* *(..)) { c.methodCount++; }
</PRE>
<p> We felt there would be too much surprise if a constructor called a
method (thus incrementing the method count) and then the field was
reset to zero after the constructor was done.
</p>
<h3><a name="WITHIN_MEMBER_TYPES">Small limitations of the within
pointcut</a></h3>
<p>Because of the guarantees made (and not made) by the Java
classfile format, there are cases where AspectJ 1.1 cannot
guarantee that the within pointcut designator will pick out all
code that was originally within the source code of a certain
type.
</p>
<p> The non-guarantee applies to code inside of anonymous and
local types inside member types. While the within pointcut
designator behaves exactly as it did in AspectJ 1.0 when given a
package-level type (like C, below), if given a member-type (like
C.InsideC, below), it is not guaranteed to capture code in
contained local and anonymous types. For example: </p>
<pre> class C {
Thread t;
class InsideC {
void setupOuterThread() {
t = new Thread(
new Runnable() {
public void run() {
// join points with code here
// might not be captured by
// within(C.InsideC), but are
// captured by within(C)
System.out.println("hi");
}
});
}
}
}
</pre>
<p> We believe the non-guarantee is small, and we haven't verified
that it is a problem in practice. </p>
<h3><a name="WITHIN_CODE">Small limitations of the withincode
pointcut</a></h3>
<p>The withincode pointcut has similar issues to those described
above for within.
</p>
<h3><a name="INSTANCEOF_ON_WILD">Can't do instanceof matching on
type patterns with wildcard</a></h3>
<p>The pointcut designators this, target and args specify a
dynamic test on their argument. These tests can not be performed
on type patterns with wildcards in them. The following code that
compiled under 1.0 will be an error in AspectJ-1.1:</p>
<pre> pointcut oneOfMine(): this(com.bigboxco..*);
</pre>
<p>The only way to implement this kind of matching in a modular
way would be to use the reflection API at runtime on the Class of
the object. This would have a very high performance cost and
possible security issues. There are two good work-arounds. If
you control the source or bytecode to the type you want to match
then you can use declare parents, i.e.:</p>
<pre> private interface OneOfMine {}
declare parents: com.bigboxco..* implements OneOfMine;
pointcut oneOfMine(): this(OneOfMine);
</pre>
<p>If you want the more dynamic matching and are willing to pay
for the performance, then you should use the Java reflection API
combined with if. That would look something like:</p>
<pre> pointcut oneOfMine(): this(Object) &&
if(classMatches("com.bigboxco..*",
thisJoinPoint.getTarget().getClass()));
static boolean classMatches(String pattern, Class _class) {
if (patternMatches(pattern, _class.getName())) return true;
...
}
</pre>
<p>Note: wildcard type matching still works in all other PCD's that
match based on static types. So, you can use
'within(com.bigboxco..*+)' to match any code lexically within one
of your classes or a subtype thereof. This is often a good
choice.</p>
</p>
<h3><a name="NO_SOURCE_COLUMN">SourceLocation.getColumn()</a></h3>
<p>The Java .class file format contains information about the
source file and line numbers of its contents; however, it has no
information about source columns. As a result, we can not
effectively support the access of column information in the
reflection API. So, any calls to
thisJoinPoint.getSourceLocation().getColumn() will be marked as
deprecated by the compiler, and will always return 0.</p>
<h3><a name="ASPECT_PRECEDENCE">Aspect precedence</a></h3>
<p> AspectJ 1.1 has a new declare form:
</p>
<pre> declare precedence ":" TypePatternList ";"
</pre>
<p> This is used to declare advice ordering constraints on join
points. For example, the constraints that (1) aspects that have
Security as part of their name should dominate all other aspects, and
(2) the Logging aspect (and any aspect that extends it) should
dominate all non-security aspects, can be expressed by: </p>
<pre> declare precedence: *..*Security*, Logging+, *;
</pre>
<p> In the TypePatternList, the wildcard * means "any type not matched
by another type in the declare precedence". </p>
<h4>Various cycles</h4>
<p> It is an error for any aspect to be matched by more than one
TypePattern in a single declare precedence, so: </p>
<pre> declare precedence: A, B, A ; // error
</pre>
<p> However, multiple declare precedence forms may legally have this
kind of circularity. For example, each of these declare precedence is
perfectly legal:
</p>
<pre> declare precedence: B, A;
declare precedence: A, B;
</pre>
<p> And a system in which both constraints are active may also be
legal, so long as advice from A and B don't share a join point. So
this is an idiom that can be used to enforce that A and B are strongly
independent. </p>
<h4>Applies to concrete aspects</h4>
<p> Consider the following library aspects:
</p>
<pre> abstract aspect Logging {
abstract pointcut logged();
before(): logged() {
System.err.println("thisJoinPoint: " + thisJoinPoint);
}
}
aspect MyProfiling {
abstract pointcut profiled();
Object around(): profiled() {
long beforeTime = System.currentTimeMillis();
try {
return proceed();
} finally {
long afterTime = System.currentTimeMillis();
addToProfile(thisJoinPointStaticPart,
afterTime - beforeTime);
}
}
abstract void addToProfile(
org.aspectj.JoinPoint.StaticPart jp,
long elapsed);
}
</pre>
<p> In order to use either aspect, they must be extended with
concrete aspects, say, MyLogging and MyProfiling. In AspectJ
1.0, it was not possible to express that Logging's advice (when
concerned with the concrete aspect MyLogging) dominated
Profiling's advice (when concerned with the concrete aspect
MyProfiling) without adding a dominates clause to Logging
itself. In AspectJ 1.1, we can express that constraint with a
simple: </p>
<pre> declare precedence: MyLogging, MyProfiling;
</pre>
<h4>Changing order of advice for sub-aspects</h4>
<p> By default, advice in a sub-aspect has more precedence than
advice in a super-aspect. One use of the AspectJ 1.0 dominates
form was to change this precedence:
</p>
<pre> abstract aspect SuperA dominates SubA {
pointcut foo(): ... ;
before(): foo() {
// in AspectJ 1.0, runs before the advice in SubA
// because of the dominates clause
}
}
aspect SubA extends SuperA {
before(): foo() {
// in AspectJ 1.0, runs after the advice in SuperA
// because of the dominates clause
}
}
</pre>
<p> This no longer works in AspectJ 1.1, since declare precedence only
matters for concrete aspects. Thus, if you want to regain this kind
of precedence change, you will need to refactor your aspects.
</p>
<h3><a name="SOURCEROOT">The -sourceroots option</a></h3>
<p> The AspectJ 1.1 compiler now accepts a -sourceroots option used to
pass all .java files in particular directories to the compiler. It
takes either a single directory name, or a list of directory names
separated with the CLASSPATH separator character (":" for various
Unices, ";" for various Windows). </p>
<p> So, if you have your project separated into a gui module and a
base module, each of which is stored in a directory tree, you might
use one of
</p>
<pre> ajc -sourceroots /myProject/gui:/myProject/base
ajc -sourceroots d:\myProject\gui;d:\myProject\base
</pre>
<p> This option may be used in conjunction with lst files, listing
.java files on the command line, and the -injars option.
</p>
<h3><a name="BYTECODE_WEAVING">The -injars option</a></h3>
<p> The AspectJ 1.1 compiler now accepts an -injars option used to
pass all .class files in a particular jar file to the compiler. It
takes either a single directory name, or a list of directory names
separated with the CLASSPATH separator character (":" for various
Unices, ";" for various Windows). </p>
<p> So, if MyTracing.java defines a trace aspect that you want to
apply to all the classes in myBase.jar and myGui.jar, you would use
one of: </p>
<pre> ajc -injars /bin/myBase.jar:/bin/myGui.jar MyTracing.java
ajc -injars d:\bin\myBase.jar;d:\bin\myGui.jar MyTracing.java
</pre>
<p> The class files in the input jars must not have had advice woven
into them, since AspectJ enforces the requirement that advice is woven
into a particular classfile only once. So if the classfiles in the
jar file are to be created with the ajc compiler (as opposed to a pure
Java compiler), they should not be compiled with any non-abstract
aspects. </p>
<p> This option may be used in conjunction with lst files, listing
.java files on the command line, and the -sourceroots option.
</p>
<h3><a name="OUTJAR">The -outjar option</a></h3>
<p> The -outjar option takes the name of a jar file into which the
results of the compilation should be put. For example:
<pre> ajc -injars myBase.jar MyTracing.java -outjar myTracedBase.jar
</pre>
<p> No meta information is placed in the output jar file. </p>
<h3><a name="INCREMENTAL">Incremental compilation</a></h3>
<p> The AspectJ 1.1 compiler now supports incremental compilation.
When ajc is called with the -incremental option, it must also be
passed a -sourceroots option specifying a directory to incrementally
compile. Once the initial compile is done, ajc waits for console
input. Every time it reads a new line (i.e., every time the user
hits return) ajc recompiles those input files that need recompiling.
</p>
<h4>Limitations</h4>
<p> This new functionality is still only lightly tested. </p>
<h3><a name="XNOWEAVE">-XnoWeave, a compiler option to suppress
weaving</a></h3>
<p> The -XnoWeave option suppresses weaving, and generates
classfiles and that can be passed to ajc again (through the
-injars option) to generate final, woven classfiles. </p>
<p> This option was originally envisioned to be the primary way to
generate binary aspects that could be linked with other code, and
so it was previously (in AspectJ 1.1beta1) named
<code>-noweave</code>. We feel that using the
<code><a href="#BINARY_ASPECTS">-aspectpath</a></code> option is a
much better option. There may still be use cases for unwoven
classfiles, but we've moved the flag to experimental status.
</p>
<h3><a name="BINARY_ASPECTS">-aspectpath, working with aspects in .class/.jar
form</a> </h3>
<p> When aspects are compiled into classfiles, they include all
information necessary for the ajc compiler to weave their advice
and deal with their inter-type declarations. In order for these
aspects to have an effect on a compilation process, they must be
passed to the compiler on the -aspectpath. Every .jar file on
this path will be searched for aspects and any aspects that are
found will be enabled during the compilation. The binary forms of
this aspects will be untouched. </p>
<h3><a name="NO_CALLEE_SIDE_CALL">Callee-side call join
points</a></h3>
<p> The 1.0 implementation of AspectJ, when given:
</p>
<pre> class MyRunnable implements Runnable {
public void run() { ... }
}
aspect A {
call(): (void run()) && target(MyRunnable) {
// do something here
}
}
</pre>
<p> would cause A's advice to execute even when, say, java.lang.Thread
called run() on a MyRunnable instance.
</p>
<p> With the new compiler, two things have happened in regard to
callee-side calls:
</p>
<ol>
<li>because the programmer has access to more code (i.e.,
bytecode, not just source code), callee-side calls are much
less important to have.</li>
<li>because compilation is more modular, allowing and
encouraging separate compilation, callee-side calls are much
more difficult to implement</li>
</ol>
<p> With these two points in mind, advice in an aspect will not be
applied to call join points whose call site is completely
unavailable to the aspect. </p>
<ol>
<li>One reason (though not the only reason) we worked so hard in
the <em>implementation</em> of 1.0.6 to expose call join
points, even if we only had access to the callee's code, was
that otherwise users couldn't get access to call join points
where the call was made from bytecode. This is no longer the
case. In short, the implementation controls much more code (or
has the capability to) than ever before.</li>
<li>The implementation model for the AspectJ 1.1 compiler is to
separate the compilation of aspects/advice from their
weaving/linking. A property of the model is that the
compilation requires no access to "target" code, only the
weaving/linking does, and weaving/linking is inherently
per-class local: No action at weaving/linking time depends on
the coordinated mangling of multiple classfiles. Rather, all
weaving is done on a per classfile basis. This is an essential
property for the current separate compilation model. <br>
However, allowing implementation of call advice on either
side requires simultaneous knowledge of both sides. If we first
have access to a call, we can't decide to simply put the advice
on the call site, since later we may decide to implement on the
callee.</li>
</ol>
<p>This implementation decision is completely in the letter and
the spirit of the AspectJ language. From the semantics guide
describing code the implementation controls:</p>
<blockquote>
But AspectJ implementations are permitted to deviate from this
in a well-defined way -- they are permitted to advise only
accesses in <em>code the implementation
controls</em>. Each implementation is free within certain
bounds to provide its own definition of what it means to control
code.
</blockquote>
<p>And about a particular decision about the 1.0.6
implementation:</p>
<blockquote>
Different join points have different requirements. Method call
join points can be advised only if ajc controls
<em>either</em> the code for the caller or the code
for the receiver, and some call pointcut designators may
require caller context (what the static type of the receiver
is, for example) to pick out join points.
</blockquote>
<p> The 1.1 implementation makes a different design decision:
Method call join points can be advised only if ajc (in compiler or
linker form) controls the code for the caller. </p>
<p>What does 1.1 gain from this?</p>
<ul>
<li>a clear (and implemented) separate compilation model (see
point 2, above)</li>
<li>a less confusing interaction between call join points and
the thisJoinPoint reflective object: We still get bug reports
about source information sometimes existing and sometimes not
existing at call join points.</li>
</ul>
<p> What does 1.1 lose from this?</p>
<ul>
<li>The ability to capture all calls to Runnable.run() from
anywhere to code ajc has access too, even from Thread, even if
you don't compile java.lang with ajc.</li>
<li>The ability to, without access to the caller, capture entry to
a particular method, but not super calls.</li>
<li>A code-size-improvement performance optimization.</li>
</ul>
<p> What are the possibilities for the future?</p>
<ul>
<li>AspectJ 1.1.1 could expand its capture of call join points,
possibly at the expense of separate compilation clarity,
possibly not. </li>
<li>AspectJ 1.1.1 could re-introduce reception join points from
AspectJ 0.7 (what callee-side call join points actually are):
though they would never ever be taught in a tutorial or
entry-level description of the model, they may have specialized
uses.</li>
</ul>
<p> How will this affect developers?</p>
<ul>
<li>When using the call PCD but only supplying the callee
code, supply the calling code or use the execution PCD instead.
</li>
</ul>
<h3><a name="OTHER_X_OPTIONS">Various -X options</a></h3>
<p> The AspectJ 1.0 compiler supported a number of options that
started with X, for "experimental". Some of them will not be
supported in 1.1, either because the "experiment" succeeded (in
which case it's part of the normal functionality) or failed.
Others will be supported as is (or nearly so) in 1.1:
</p>
<ul>
<li>-XOcodeSize: This is no longer necessary because inlining
of around advice is on by default. We support its inverse,
<a href="#XNOINLINE"><code>-XnoInline</code></a>.
</li>
<li><a href="#XNOWEAVE">-XnoWeave, a compiler option to suppress
weaving</a></li>
<li>-XtargetNearSource: Not supported in this release. </li>
<li>-XserializableAspects: Supported. </li>
<li>-XaddSafePrefix: This option will not be supported in 1.1 at
all because we're now always using (what we believe to be) safe
prefixes. </li>
<li>-Xlint: Still supported, with <a href="#XLINT">various
options</a>. </li>
</ul>
<h3><a name="ERROR_MESSAGES">Some confusing error messages</a></h3>
<p>Building on the eclipse compiler has given us access to a very
sophisticated problem reporting system as well as highly optimized
error messages for pure Java code. Often this leads to noticeably
better error messages than from ajc-1.0.6. However, when we don't
handle errors correctly this can sometimes lead to cascading error
messages where a single small syntax error will produce dozens of
other messages. Please report any very confusing error messages as
bugs.</p>
<h3><a name="MESSAGE_CONTEXT">Source code context is not shown
for errors and warnings detected during bytecode weaving</a></h3>
<p>For compiler errors and warnings detected during bytecode weaving,
source code context will not be displayed. In particular, for declare
error and declare warning statements, the compiler now only emits the
file and line. We are investigating ways to overcome this in cases
where the source code is available; in cases where source code is
not available, we might specify the signature of the offending code.
For more information, see bug 31724.</p>
<h3><a name="XLINT">The -Xlint option</a></h3>
<p><code>-Xlint:ignore,error,warning</code> will set the level for
all Xlint warnings. <code>-Xlint</code>, alone, is an
abbreviation for <code>-Xlint:warning</code>.</p>
<p>The <code>-Xlintfile:lint.properties</code> allows fine-grained
control. In tools.jar, see
<code>org/aspectj/weaver/XlintDefault.properties</code> for the
default behavior and a template to copy. </p>
<p> More <code>-Xlint</code> warnings are supported now, and
we may add disabled warnings in subsequent bug-fix releases of 1.1.
Because the configurability allows users to turn off
warnings, we will be able to warn about more potentially
dangerous situations, such as the potentially unsafe casts used by
very polymorphic uses of proceed in around advice. </p>
<h3><a name="NO_SOURCE">Source-specific options</a></h3>
<p> Because AspectJ 1.1 does not generate source code after
weaving, the source-code-specific options -preprocess, -usejavac,
-nocomment and -workingdir options are meaningless and so not
supported. </p>
<h3><a name="NO_STRICT_LENIENT">The -strict and -lenient
options</a></h3>
<p> Because AspectJ 1.1 uses the Eclipse compiler, which has its
own mechanism for changing strictness, we no longer support the
-strict and -lenient options. </p>
<h3><a name="NO_PORTING">The -porting option</a></h3>
<p> AspectJ 1.1 does not have a -porting option.</p>
<h3><a name="13_REQUIRED">J2SE 1.3 required</a></h3>
<p>Because we build on Eclipse, the compiler will no longer run
under J2SE 1.2. You must run the compiler (and all tools based on
the compiler) using J2SE 1.3 or later. The code generated by the
compiler can still run on Java 1.1 or later VM's if compiled against
the correct runtime libraries.</p>
<h3><a name="DEFAULT_CONSTRUCTOR_CONFLICT">Default
constructors</a></h3>
<p> AspectJ 1.1 does not allow the inter-type definition of a
zero-argument constructor on a class with a visible default
constructor. So this is no longer allowed: </p>
<PRE>
class C {}
aspect A {
C.new() {} // was allowed in 1.0.6
// is a "multiple definitions" conflict in 1.1
}
</PRE>
<p> In the Java Programming Language, a class defined without a
constructor actually has a "default" constructor that takes no
arguments and just calls <code>super()</code>. </p>
<p> This default constructor is a member of the class like any other
member, and can be referenced by other classes, and has code generated
for it in classfiles. Therefore, it was an oversight that AspectJ
1.0.6 allowed such an "overriding" inter-type constructor definition.
</p>
<h3><a name="SUPER_IFACE_INITS">Initialization join points for
super-interfaces</a></h3>
<p> In AspectJ, interfaces may have non-static members due to
inter-type declarations. Because of this, the semantics of AspectJ
defines the order that initializer code for interfaces is run.
</p>
<p> In the semantics document for AspectJ 1.0.6, the following
promises were made about the order of this initialization:
</p>
<ol>
<li>a supertype is initialized before a subtype</li>
<li>initialized code runs only once</li>
<li>initializers for supertypes run in left-to-right order</li>
</ol>
<p> The first two properties are important and are preserved in
AspectJ 1.1, but the third property is and was ludicrous, and was
never properly implemented (and never could be) in AspectJ 1.0.6.
Consider: </p>
<PRE>
interface Top0 {}
interface Top1 {}
interface I extends Top0, Top1 {}
interface J extends Top1, Top0 {}
class C implements I, J {}
// I says Top0's inits must run before Top1's
// J says Top1's inits must run before Top0's
aspect A {
int Top0.i = foo("I'm in Top0");
int Top1.i = foo("I'm in Top1");
static int foo(String s) {
System.out.println(s);
return 37;
}
}
</PRE>
<p> This was simply a bug in the AspectJ specification. The correct
third rule is:
</p>
<blockquote>the initializers for a type's superclass are run before the
initializers for its superinterfaces.
</blockquote>
<h3><a name="VOID_FIELD_SET">Field Set Join Points</a></h3>
<p> In AspectJ 1.0.6, the join point for setting a field F had, as a
return type, F's type. This was "java compatible" because
field assignment in java, such as "Foo.i = 37", is in fact an
expression, and does in fact return a value, the value that the
field is assigned to.
</p>
<p> This was never "java programmer compatible", however, largely
because programmers have absorbed the good style of rarely using an
assignment statement in a value context. Programmers typically expect
"Foo.i = 37" not to return a value, but to simply assign a value. </p>
<p> Thus, programmers typically wanted to write something like:
</p>
<PRE>
void around(): set(int Foo.i) {
if (theSetIsAllowed()) {
proceed();
}
}
</PRE>
<p> And were confused by it being a compile-time error. They weren't
confused for long, and soon adapted to writing:
</p>
<PRE>
int around(): set(int Foo.i) {
if (theSetIsAllowed()) {
return proceed();
} else {
return Foo.i;
}
}
</PRE>
<p> But there was definitely a short disconnect. </p>
<p> On top of that, we were never shown a convincing use-case for
returning an interesting value from a set join point. When we
revisited this issue, in fact, we realized we had a long-standing bug
in 1.0.6 dealing with the return value of pre-increment expressions
(such as ++Foo.i) that nobody had found because nobody cares about the
return value of such join points.
</p>
<p> So, because it's easier to implement, and because we believe that
this is the last possibility to make the semantics more useful, we
have made set join points have a void return type in 1.1. </p>
<h3><a name="XNOINLINE">The -XnoInline Option</a></h3>
<p> The <code>-XnoInline</code>
option to indicate that no inlining of any kind should be done. This
is purely a compiler pragma: No program semantics (apart from stack
traces) will be changed by the presence or absence of this option.
</p>
<h3><a name="TARGET_TYPES_MADE_PUBLIC">Target types made
public</a></h3>
<p> Even in 1.0.6, the AspectJ compiler has occasionally needed to
convert the visibility of a package-level class to a public one. This
was previously done in an ad-hoc basis that took whole-program
analysis into account. With the incremental compilation model of
AspectJ 1.1, we can now specify the occasions when the compiler makes
these visibility changes.
</p>
<p> In particular, the types used in the <code>this</code>,
<code>target</code>, and <code>args</code> pointcuts are made public,
as are the super-types from <code>declare parents</code> and the
exception type from <code>declare soft</code>.
</p>
<p> We believe the visibility changes could be avoided in the future
with various implementation tricks if they become a serious
concern, but did not encounter them as such a concern when they were
done in the 1.0.6 implementation. </p>
<h3><a name="STRINGBUFFER">String + now advised</a></h3>
<p> In Java, the + operator sometimes results in StringBuffer objects
being created, appended to, and used to generate a new String. Thus,
</p>
<PRE>
class Foo {
String makeEmphatic(String s) {
return s + "!";
}
}
</PRE>
<p> is approximately the same at runtime as
</p>
<PRE>
class Foo {
String makeEmphatic(String s) {
return new StringBuffer(s).append("!").toString();
}
}
</PRE>
<p> In the design process of AspectJ 1.0.6 we didn't expose those
StringBuffer methods and constructors as join points (though we did
discuss it), but in 1.1 we do. </p>
<p> This change is likely to affect highly wildcarded aspects, and can
do so in surprising ways. In particular:
</p>
<PRE>
class A {
before(int i): call(* *(int)) && args(i) {
System.err.println("entering with " + i);
}
}
</PRE>
<p> may result in a stack overflow error, since the argument to
println is really </p>
<PRE>
new StringBuffer("entering with ").append(i).toString()
</PRE>
<p> which has a call to StringBuffer.append(int). In such cases, it's
worth restricting your pointcut, with something like one of:
</p>
<PRE>
call(* *(int)) && args(i) && !within(A)
call(* *(int)) && args(i) && !target(StringBuffer)
</PRE>
<h3><a name="ONE_FOUR_METHOD_SIGNATURES">The -1.4 flag and method signatures</a></h3>
<p> Consider the following aspect
</p>
<PRE>
public aspect SwingCalls {
pointcut callingAnySwing(): call(* javax.swing..*+.*(..));
before(): callingAnySwing() {
System.out.println("Calling any Swing");
}
}
</PRE>
<p> And then consider the two statements
</p>
<PRE>
JFrame frame = new JFrame();
frame.setTitle("Title");
</PRE>
<p> According to the Java Language Specification version 2, the call
to <code>frame.setTitle("Title")</code> should always produce the
bytecode for a call to <code>javax.swing.JFrame.setTitle</code>.
However, older compilers (and eclipse when run without the
<code>-1.4</code> flag) will generate the bytecode for a call to
<code>java.awt.Frame.setTitle</code> instead since this method is not
overriden by JFrame. The AspectJ weaver depends on the correctly
generated bytecode in order to match patterns like the one you show
correctly. </p>
<p> This is a good example of why the pattern <code>call(* *(..)) &&
target(JFrame)</code> is the recommended style. In general, OO
programmers don't want to care about the static type of an object at a
call site, but only want to know the dynamic instanceof behavior which
is what the target matching will handle. </p>
<h2><a name="knownLimitations">Known limitations</a></h2>
<p>The AspectJ 1.1.0 release contains a small number of known limitations
relative to the AspectJ 1.1 language.
For the most up-to-date information about known limitations in an
AspectJ 1.1 release, see the bug database at
<a href="http://bugs.eclipse.org/bugs">http://bugs.eclipse.org/bugs</a>,
especially the open bugs for the
<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
compiler</a>,
<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=IDE&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
IDE support</a>,
<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Doc&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
documentation</a>, and
<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Ant&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">
Ant tasks</a>.
Developers should know about bugs marked with the "info" keyword
because those bugs reflect failures to implement the 1.1 language perfectly.
These might be fixed during the 1.1 release cycle; find them using the query
<a href="http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info">
http://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info</a>
For ajc's 1.1 implementation limitations, see
<a href="progguide/implementation.html">
Programming Guide Appendix: "Implementation Notes"</a>.
</p>
</body> </html>
|
