blob: e15d52cd1d34b4e32c2ab64600deb49620ce77be (
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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 1.6.8 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 2009 Contributors.
All rights reserved.
</small></div>
<h1>AspectJ 1.6.8 Readme</h1>
<p>The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some radical internal changes.'</p>
<p>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.</p>
<h2>Incorrect treatment of some aop.xml include/exclude patterns</h2>
<p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786">Bug 298786</a></p>
<p>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: </p>
<ul>
<li>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)
<li>you need two include patterns - one that is being optimized and one that is not
</ul>
<p>
These three meet that spec:</p>
<code><pre>
<include within="*"/>
<include within="@Foo *"/>
<exclude within="*Funk*y*"/>
</pre></code>
<p>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).</p>
<p>With that configuration any types that the include="*" would have accepted are
not accepted.</p>
<h2>Stack overflow problem in ReferenceType.isAssignableFrom()</h2>
<p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908">Bug 298908</a></p>
<p>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.</p>
<p>The stack trace when this is hit looks like:</p>
<code><pre>
...
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)
...
</pre></code>
<p>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.</p>
<p>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.</p>
<hr>
Thanks to everyone who helped get to the bottom of these problems.
<h4>
<!-- ============================== -->
</body>
</html>
|
