diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/dist/doc/README-168.html | 91 | ||||
| -rw-r--r-- | docs/dist/doc/index.html | 1 |
2 files changed, 92 insertions, 0 deletions
diff --git a/docs/dist/doc/README-168.html b/docs/dist/doc/README-168.html new file mode 100644 index 000000000..e15d52cd1 --- /dev/null +++ b/docs/dist/doc/README-168.html @@ -0,0 +1,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> diff --git a/docs/dist/doc/index.html b/docs/dist/doc/index.html index 804125132..15fbdd977 100644 --- a/docs/dist/doc/index.html +++ b/docs/dist/doc/index.html @@ -138,6 +138,7 @@ <tr> <td>README's </td> <td>Changes and porting guide for AspectJ + <a href="README-168.html">1.6.8</a>, <a href="README-167.html">1.6.7</a>, <a href="README-166.html">1.6.6</a>, <a href="README-165.html">1.6.5</a>, |