blob: 0a8e3cbb80231783e478f71633ce4c40d36e1d80 (
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
|
[.small]#© Copyright 2009 Contributors. All rights reserved.#
== AspectJ 1.6.8 Readme
The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some
radical internal changes.'
Unfortunately not enough testing was done on 1.6.7 and two nasty issues
were found that really needed addressing. Fixes for these issues are all
that is new in 1.6.8.
=== Incorrect treatment of some aop.xml include/exclude patterns
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786[Bug 298786]
Basically, if a certain combination of includes and excludes were
specified in the within section, then the weaver would fail to merge
them correctly. The conditions for the failure are:
* you need an exclude pattern that the weaver is not optimizing for
(basically a pattern that could not be matched based upon the typename
alone, eg. based on whether the type has an annotation)
* you need two include patterns - one that is being optimized and one
that is not
These three meet that spec:
[source, xml]
....
<include within="*"/>
<include within="@Foo *"/>
<exclude within="*Funk*y*"/>
....
The include="*" can be optimized. The include="@Foo *" is not optimized.
The exclude="*Funk*y*" is not optimized (this one could be but isn't
right now as it includes multiple wildcards).
With that configuration any types that the include="*" would have
accepted are not accepted.
=== Stack overflow problem in ReferenceType.isAssignableFrom()
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908[Bug 298908]
This is actually a problem AspectJ has had for a long time, but has
always proved elusive to recreate. It turns out that it is memory
related and the more aggressive policy in 1.6.7 causes it to occur much
more frequently.
The stack trace when this is hit looks like:
[source, text]
....
...
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
...
....
The weaver has changed over the 1.5 and 1.6 releases and is now reaching
a point where it really shrinks quite small when not in use (maybe in a
loadtime environment you have finished loading all your classes). The
aim is that it can rebuild any required state that is needed later. With
the move in 1.6.7 from Soft to Weak references, things are being
discarded much sooner and this is exercising the state rebuilding code
that wasn't used that often prior to 1.6.7.
The problem is actually because the call on a generic type to get the
raw type was actually broken and returning the generic type. This then
loops forever trying to get the raw type from the generic type. This
happens because the world should store only raw types (which point to
their generic form) but there was a bug in state rebuilding that instead
put the generic type directly in the world.
'''''
Thanks to everyone who helped get to the bottom of these problems.
|
