blob: 5e37c8efb7e697d7493a99e0b78b85652754cee6 (
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
|
== AspectJ 1.6.0
_© Copyright 2008 Contributors. All rights reserved._
=== AspectJ v1.6.0 - 23 Apr 2008
For the complete list of every issue addressed since the last full
release, see
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=[this
bugzilla link].
Some of the highlights of 1.6.0 are:
==== Upgrade to a Java 1.6 compiler
AspectJ1.6.0 upgrades the internal Eclipse compiler level to version
785_R33x - a Java 1.6 level compiler
==== Better incremental compilation support in the IDE
Changes under https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[bug
221427] mean that the compiler is better able to maintain incremental
state for projects in Eclipse and determine whether full builds or
incremental builds are required when project dependencies change. The
result is that the compiler will more frequently do an incremental build
rather than falling back to doing a full build. Some basic performance
findings can be seen in
https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html[this
mailing list post].
==== Parameter annotation matching
Parameter matching is possible for constructors and methods. The use of
parentheses around the parameter types in a method signature determine
whether the annotations relate to the type of the parameter or the
parameter itself.
[source, java]
....
execution(* *(@A *));
....
- Execution of a method/ctor whose first parameter is of a type
annotated with @A.
[source, java]
....
execution(* *(@A (*)));
....
- Execution of a method/ctor whose first parameter is annotated with @A
[source, java]
....
execution(* *(@A (@B *)))
....
- Execution of a method/ctor whose first parameter is annotated with @A
and is of a type annotated with @B. Example:
[source, java]
....
// ------ Start of Test.java -----
@interface A {}
@interface B {}
class C {
public void foo(@A String s) {}
public void goo(@A @B String s) {}
}
aspect X {
before(): execution(* *(@A (*))) {}
before(): execution(* *(@B (*))) {}
}
// ------ End of Test.java -----
....
[source, text]
....
$ ajc -showWeaveInfo -1.6 Test.java
Join point 'method-execution(void C.foo(java.lang.String))' in Type 'C' (A.java:5) advised by before advice from 'X' (A.java:10)
Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:11)
Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:10)
....
The first piece of advice matched both methods. The second only matched `goo()`.
==== Annotation Value Matching
This allows static matching of the values of an annotation - if the
matching is done statically at weave time, it is possible to avoid some
of the reflection that is currently required within the advice (in some
cases). A typical use case is tracing where the trace level is defined
by an annotation but may be switched OFF for a method if the annotation
has a particular value. Perhaps tracing has been turned on at the type
level and a few critical methods should not get traced. Here is some
code showing the use case:
[source, java]
....
enum TraceLevel { NONE, LEVEL1, LEVEL2, LEVEL3 }
@interface Trace {
TraceLevel value() default TraceLevel.LEVEL1;
}
aspect X {
// Advise all methods marked @Trace except those with a tracelevel of none
before(): execution(@Trace !@Trace(TraceLevel.NONE) * *(..)) {
System.err.println("tracing "+thisJoinPoint);
}
}
public class ExampleOne {
public static void main(String[] args) {
ExampleOne eOne = new ExampleOne();
eOne.m001();
eOne.m002();
eOne.m003();
eOne.m004();
eOne.m005();
eOne.m006();
eOne.m007();
}
@Trace(TraceLevel.NONE)
public void m001() {}
@Trace(TraceLevel.LEVEL2)
public void m002() {} // gets advised
@Trace(TraceLevel.LEVEL3)
public void m003() {} // gets advised
@Trace(TraceLevel.NONE)
public void m004() {}
@Trace(TraceLevel.LEVEL2)
public void m005() {} // gets advised
@Trace(TraceLevel.NONE)
public void m006() {}
@Trace
public void m007() {} // gets advised
}
....
Matching is currently allowed on all annotation value types *except*
class and array. Also it is not currently supported for parameter
annotation values.
==== Changes since release candidate
The only fix 1.6.0 final includes beyond the release candidate is a
multi-threading problem in the weaver -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029[bug 227029].
==== Releases leading up to AspectJ 1.6.0
AspectJ v1.6.0rc1- 16 Apr 2008
AspectJ v1.6.0M2 - 26 Feb 2008
AspectJ v1.6.0M1 - 16 Jan 2008
'''''
|
