123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596 |
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
- <html> <head>
- <title>AspectJ 1.6.11 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 2010-2011 Contributors.
- All rights reserved.
- </small></div>
-
- <h1>AspectJ 1.6.11 Readme</h1>
-
- <p>The full list of resolved issues in 1.6.11 is available
- <a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.11;">here</a></h2>.</p>
-
- <h4>1.6.11 available 15-03-2011</h4>
-
-
- <h2>Notable Changes</h2>
- <h3>RC1 - Our own XML parser</h3>
- <p>Due to the way AspectJ loads one of the standard XML parsers (for processing aop.xml) it was possible to get into a deadlock situation.
- To avoid this completely we now have our own XML parser inside for processing this files. It is basic but should support all the
- known syntax we have for aop files. To use it instead of the default (if you are encountering the deadlock) you need to specify
- this system property: <tt>org.aspectj.weaver.loadtime.configuration.lightxmlparser=true</tt>.
- </p>
- <hr>
-
- <h3>M2 - Multithreaded world access</h3>
- <p>The weaver is backed by a representation of types called a world. Traditionally the worlds have supported single threads - and that
- is how they are used when doing compile time weaving or load time weaving. However in some configurations, e.g. pointcut
- matching under Spring, a single world instance may be getting accessed by multiple threads at the same time. Under
- <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=337855">bug337855</a> some changes have been made to better support this kind
- of configuration.</p>
-
- <h3>M2 - various attribute deserialization issues</h3>
- <p>In 1.6.9 we made some radical changes to the serialized form. It turns out some of the
- deserialization code wasn't handling these new forms quite right. This would manifest as an IllegalStateException or
- IndexOutOfBoundsException or similar, during attribute unpacking. These issues have now all been sorted out in 1.6.11.M2.</p>
-
- <h3>M2 - further optimizations in model for AJDT</h3>
- <p>More changes have been made for users trying out the <tt>-Xset:minimalModel=true</tt> option to try and reduce the memory used in
- their Eclipse/AJDT configurations. This option is discussed in detail <a href="http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html">here</a>.
- It now saves even more memory. Also, previously the amount of memory it recovered depended on compilation order (which the user has no control over), but now
- it is insensitive to ordering and should always recover the same amount across builds of the same project. With a bit more positive feedback on this option,
- it will become the default under AJDT.</p>
-
- <h3>M2 - spaces in path names can cause problems</h3>
- <p>AspectJ had problems if the paths it was being passed (e.g. aspectpath) included spaces.
- This is bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=282379">282379</a> and has now been fixed.</p>
-
- <hr>
-
- <h3>M1 - Annotation removal</h3>
- <p>Traditionally AspectJ has taken an additive approach, where methods/fields/supertypes/annotations can only be added to types.
- Now, chaos would likely ensue if we allowed removal of supertypes, methods, etc, but we are seeing an increasing number of
- requirements to do more with annotations. What kinds of thing? Basically remove existing annotations, or modify existing
- annotations by changing their values.
- 1.6.11 includes a new piece of syntax that we are thinking might be appropriate for one of these scenarios. 1.6.11 supports this:
- <pre><code>declare @field: int Foo.i: -@Anno;
- </code></pre>
- <p>Notice the '-' in front of the annotation, meaning 'removal'. The whole construct means 'remove the @Anno annotation from the
- int field called i in type Foo'. It is not yet supported on the other forms of declare @.
-
- <h3>M1 - Intertype innertypes</h3>
- <p>More work has gone into this feature. It was originally added in 1.6.9 but the inability to use it with binary weaving
- greatly reduced the usefulness. Fixes have gone into 1.6.11 to support binary weaving. What do we mean by intertype innertypes?
- Here is an example:
-
- <pre><code>class Foo {
- public void m() {
- System.out.println(Inner.i);
- }
- }
-
- aspect X {
- public static class Foo.Inner {
- static int i = 34;
- }
- }
- </code></pre>
- <p>Only static inner types are supported.
-
- <h4>
- <!-- ============================== -->
- </body>
- </html>
|