doc/released/README-1611.html - gerrit/www.eclipse.org/aspectj - Git at Google

 <!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>
 &copy; 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>
	<!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>