summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--docs/dist/doc/README-168.html91
-rw-r--r--docs/dist/doc/index.html1
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>
+&copy; 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>
+ &lt;include within="*"/&gt;
+ &lt;include within="@Foo *"/&gt;
+ &lt;exclude within="*Funk*y*"/&gt;
+</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>,