| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| <html> <head> |
| <title>AspectJ 1.6.12 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.12 Readme</h1> |
| |
| <p>The full list of resolved issues in 1.6.12 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.12;">here</a></h2>.</p> |
| |
| <h4>1.6.12 released 18-Oct-2011</h4> |
| <h4>1.6.12.RC1 available 3-Oct-2011</h4> |
| <h4>1.6.12.M2 available 18-Aug-2011</h4> |
| <h4>1.6.12.M1 available 7-Jun-2011</h4> |
| |
| <h2>Notable Changes</h2> |
| |
| <h3>RC1 - annotation value matching and !=</h3> |
| <p> |
| Prior to this change it was only possible to specify an annotation match like this:<br><br> |
| <tt>get(@Anno(someValue=1) * *) || get(@Anno(someValue=3) * *)</tt><br> |
| <p>Now it is possible to use != and write this:<br><br> |
| <tt>get(@Anno(someValue!=2) * *)</tt><br> |
| <p>This can enable a group of annotated elements to be more easily identified.<br> |
| <br> |
| |
| |
| <h3>RC1 - More flexible pointcut/code wiring in aop.xml</h3> |
| <p> |
| Prior to this version the wiring was quite limited. In order to wire a pointcut to a piece of code the user |
| needed to write an abstract aspect that included an abstract pointcut and some advice attached to that |
| abstract pointcut. Then compile this aspect and finally write the XML to concretize the abstract pointcut. With 1.6.12 |
| more flexibility has been added and for some cases there can be no need for that abstract aspect. |
| <p>This is a work in progress but now you can write this in the aop.xml: |
| <pre><code> |
| <concrete-aspect name="MyAspect"> |
| <before pointcut="execution(* Hello.say2(..)) AND args(message)" |
| invokeClass="SomeRegularJavaClass" |
| invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/> |
| <after pointcut="execution(* Hello.say2(..)) AND args(message)" |
| invokeClass="SomeRegularJavaClass" |
| invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/> |
| </concrete-aspect> |
| |
| public class SomeRegularJavaClass { |
| |
| public static void someMethod(org.aspectj.lang.JoinPoint tjp, String s) { |
| System.out.println("in advice4: s="+s+" at "+tjp); |
| } |
| |
| public static void someOtherMethod(org.aspectj.lang.JoinPoint tjp, String s) { |
| System.out.println("in advice5: s="+s+" at "+tjp); |
| } |
| } |
| </code></pre> |
| <p>In this example there is a simple regular java class containing some static methods. In the XML these |
| can be joined to pointcuts, kind as if they were advice. Notice in the XML it specifies: |
| <ul> |
| <li>The pointcut |
| <li>The <tt>invokeClass</tt> - the fully qualified name of the class containing the Java method |
| <li>The <tt>invokeMethod</tt> - the method, including signature in the specified class. |
| </ul> |
| <p> |
| Due to the method specification being in XML the parameter types must be fully specified. The only |
| exception to this rule is that the AspectJ core types JoinPoint (and JoinPoint.StaticPart) do not |
| have to be fully qualified (see the example above). |
| <b>Important:</b> notice that in the case above which does argument binding, the names are |
| bound according to the XML specification, not according to the parameter names in the Java code. |
| <p>Around advice is also supported (the return type of the method must match the joinpoint return |
| type). The example shows after advice, currently there is no way to specify either after returning |
| or after finally, there is only after. |
| <p>Expanding this further would enable support for all the code style features in the XML. Some |
| of the language features like declare annotation cannot be done in annotation style aspects but the |
| XML doesn't have the same kind of restrictions. If anyone wants to help out by fleshing this area |
| of the weaver out, let me know and I'll help you get started! |
| |
| <hr> |
| <h3>M2 - thisAspectInstance (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649">bug239649</a>)</h3> |
| <p> |
| There is now a new well known name that you can use in the if clauses in your aspects. <tt>thisAspectInstance</tt> provides access to the aspect instance. |
| |
| Here is an example: |
| |
| <code><pre>aspect X { |
| boolean doit() { |
| System.out.println("In instance check method doit()"); |
| return true; |
| } |
| |
| before():execution(* m(..)) && if(thisAspectInstance.doit()){ |
| System.out.println(thisJoinPoint); |
| } |
| }</pre></code> |
| |
| <p>Now why not just use <tt>X.aspectOf()</tt> instead of <tt>thisAspectInstance</tt>? Well <tt>thisAspectInstance</tt> is quite useful |
| when working with abstract/concrete aspects: |
| |
| <code><pre> |
| abstract aspect X { |
| abstract pointcut p(); |
| |
| boolean doit() { |
| return true; |
| } |
| |
| before():p() && if(thisAspectInstance.doit()){ |
| System.out.println(thisJoinPoint); |
| } |
| } |
| |
| aspect Y extends X { |
| |
| pointcut p(): execution(* m(..)); |
| |
| }</pre></code> |
| |
| <p>Now <tt>thisAspectInstance</tt> will be an instance of the Y, not X. |
| |
| It enables the aspect instance to be used in some kind of check/guard that will avoid the costly creation of a thisJoinPoint object if |
| the advice isn't going to run. |
| |
| <b>Note:</b> right now this only works for singleton aspects. If you have need of it with other instantiation models, please comment on |
| <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649">https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649</a> |
| </p> |
| <h3>M2 - weaving groovy</h3> |
| <p> |
| Although we have been successfully weaving groovy for a long time, it is becoming more popular and a few issues have been uncovered |
| when using non-singleton aspects with groovy code. These have been fixed. |
| </p> |
| |
| <h3>M2 - AJDT memory</h3> |
| <p> |
| The release notes for the last few versions of AspectJ have mentioned two options (minimalModel and typeDemotion) which can be |
| switched on to reduce memory consumption. They have had enough field testing now and from 1.6.12.M2 onwards they are on by default. |
| Users should see a reduction in memory consumed by AspectJ projects in AJDT. It won't affect load time weaving. It may also help |
| command line (or Ant) compile time weaving. If these options cause a problem then please raise a bugzilla but in the interim you could |
| work around the problem by actively turning them off by |
| specifying <tt>-Xset:minimalModel=false,typeDemotion=false</tt> in the project properties for your AspectJ project. |
| </p> |
| |
| <h3>M2 - Java7 weaving support</h3> |
| <p>Some preliminary work has been done to support Java7. Java7 class files must contain the necessary extra verifier support attributes |
| in order to load successfully on a Java7 VM - the attributes were only optional in Java6. It is possible to force loading of classes missing |
| the attributes but that requires use of a -XX option. AspectJ 1.6.12.M2 should create these for you if you weave Java7 level class |
| files. Nothing has been done yet to rebase AspectJ on a version of the Eclipse compiler that supports Java7 language constructs - |
| that will happen after Eclipse 3.7.1 is out. |
| </p> |
| |
| <hr> |
| <h3>M1 - synthetic is supported in pointcut modifiers <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=327867">327867</a></h3> |
| <p>It is now possible to specify synthetic in pointcuts: |
| </p> |
| <pre><code>pointcut p(): execution(!synthetic * *(..)); |
| </code></pre> |
| |
| <h3>M1 - respect protection domain when generating types during weaving <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=328099">328099</a></h3> |
| <p>This enables us to weave signed jars correctly. AspectJ sometimes generates closure classes during weaving and |
| these must be defined with the same protection domain as the jar that gave rise to them. In 1.6.12.M1 this should |
| now work correctly. |
| </p> |
| |
| <h3>M1 - Suppressions inline with the JDT compiler <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=335810">335810</a></h3> |
| <p>Starting with Eclipse 3.6, the Eclipse compiler no longer suppresses raw type |
| warnings with @SuppressWarnings("unchecked"). You need to use |
| @SuppressWarnings("rawtypes") for that. AspectJ has now been updated with this rule too. |
| </p> |
| |
| <h3>M1 - Optimized annotation value binding for ints <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=347684">347684</a></h3> |
| <p>The optimized annotation value binding now supports ints - this is for use when you want to match upon the existence of an annotation but |
| you don't need the annotation, you just need a value from it. This code snippet shows an example:</p> |
| <pre><code>@interface SomeAnnotation { |
| int i(); |
| } |
| |
| before(int i): execution(* *(..)) && @annotation(SomeAnnotation(i)) { |
| </code></pre> |
| <p> |
| Binding values in this way will result in code that runs *much* faster than using pointcuts that |
| bind the annotation itself then pull out the value. |
| </p> |
| |
| <p>Under that same bug some changes were made to match values by name when binding too. Suppose the annotation |
| had multiple int values, how would we select which int to bind? AspectJ will now use the name (if it can) to select |
| the right value: |
| <pre><code>@interface SomeAnnotation { |
| int mods(); |
| int flags(); |
| } |
| |
| before(int flags): execution(* *(..)) && @annotation(SomeAnnotation(flags)) { |
| </code></pre> |
| <p>Here the use of 'flags' as the name of the value being bound will ensure the 'flags' value from any SomeAnnotation is |
| bound and not the 'mods' value.</p> |
| |
| |
| <h4> |
| <!-- ============================== --> |
| </body> |
| </html> |
