|
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687 |
- = AspectJ 1.6.8
-
- _© Copyright 2009 Contributors. All rights reserved._
-
- 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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786[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:
-
- * 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)
- * you need two include patterns - one that is being optimized and one
- that is not
-
- These three meet that spec:
-
- [source, xml]
- ....
- <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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908[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:
-
- [source, text]
- ....
- ...
- 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.
|