12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091 |
- <!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>
|