From: aclement Date: Fri, 8 Jan 2010 21:54:17 +0000 (+0000) Subject: 168 X-Git-Tag: V1_6_8~1 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=0ef1b6e99b7bc08536c29a72413ed41d04bb2af2;p=aspectj.git 168 --- 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 @@ + + +AspectJ 1.6.8 Readme + + + + +
+© 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 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:

+ +

+These three meet that spec:

+
+    <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 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:

+ +
+	...
+	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. + +

+ + + 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 @@ README's Changes and porting guide for AspectJ + 1.6.8, 1.6.7, 1.6.6, 1.6.5,