<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 6 Development Kit v1.6.0 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 2008 Contributors.
All rights reserved.
</small></div>

<h1>AspectJ v1.6.0 Readme</h1>

<h3>AspectJ v1.6.0 - 23 Apr 2008</h3>

<p>For the complete list of every issue addressed since the last full release, see
<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">this bugzilla link</a>.

<p>Some of the highlights of 1.6.0 are:

<h4>Upgrade to a Java 1.6 compiler</h4>
<p>AspectJ1.6.0 upgrades the internal Eclipse compiler level to version 785_R33x - a Java 1.6 level compiler</p>

<h4>Better incremental compilation support in the IDE</h4>
<p>Changes under <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427">bug 221427</a> mean that the compiler 
is better able to maintain incremental state for projects in Eclipse and determine whether full builds or incremental
builds are required when project dependencies change.  The result is that the compiler will more frequently do
an incremental build rather than falling back to doing a full build.  Some basic performance findings can be seen in
<a href="http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html">this mailing list post</a>.

<h4>Parameter annotation matching</h4>
<p>Parameter matching is possible for constructors and methods.  The use
of parentheses around the parameter types in a method signature
determine whether the annotations relate to the type of the parameter
or the parameter itself.

<pre><code>
execution(* *(@A *));
</code></pre>
<p>- Execution of a method/ctor whose first parameter is of a type
annotated with @A.

<pre><code>
execution(* *(@A (*)));
</code></pre>
<p>- Execution of a method/ctor whose first parameter is annotated with @A

<pre><code>
execution(* *(@A (@B *)))
</code></pre>
<p>- Execution of a method/ctor whose first parameter is annotated with
@A and is of a type annotated with @B.

Example:
<pre><code>
------ Start of Test.java -----
@interface A {}
@interface B {}

class C {
 public void foo(@A String s) {}
 public void goo(@A @B String s) {}
}

aspect X {
 before(): execution(* *(@A (*))) {}
 before(): execution(* *(@B (*))) {}
}
------ End of Test.java -----
$ ajc -showWeaveInfo -1.6 Test.java
Join point 'method-execution(void C.foo(java.lang.String))' in Type 'C' (A.java:5) advised by before advice from 'X' (A.java:10)

Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:11)

Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:10)
</code></pre>
<p>The first piece of advice matched both methods.  The second only matched goo().
<br><br>
<h4>Annotation Value Matching</h4>

<p>This allows static matching of the values of an annotation - if the matching is done statically at weave time, it is possible
to avoid some of the reflection that is currently required within the advice (in some cases).  A typical use case is tracing where
the trace level is defined by an annotation but may be switched OFF for a method if the annotation has a particular value.  Perhaps
tracing has been turned on at the type level and a few critical methods should not get traced.  Here is some code showing the
use case:
<p>

<pre><code>
enum TraceLevel { NONE, LEVEL1, LEVEL2, LEVEL3 }

@interface Trace {
  TraceLevel value() default TraceLevel.LEVEL1;
}
  
aspect X {
  // Advise all methods marked @Trace except those with a tracelevel of none
  before(): execution(@Trace !@Trace(TraceLevel.NONE) * *(..)) {
    System.err.println("tracing "+thisJoinPoint);
  }
}

public class ExampleOne {

  public static void main(String[] args) {
    ExampleOne eOne = new ExampleOne();
    eOne.m001();
    eOne.m002();
    eOne.m003();
    eOne.m004();
    eOne.m005();
    eOne.m006();
    eOne.m007();
  }

  @Trace(TraceLevel.NONE)
  public void m001() {}

  @Trace(TraceLevel.LEVEL2)
  public void m002() {} // gets advised

  @Trace(TraceLevel.LEVEL3)
  public void m003() {} // gets advised

  @Trace(TraceLevel.NONE)
  public void m004() {}

  @Trace(TraceLevel.LEVEL2)
  public void m005() {} // gets advised

  @Trace(TraceLevel.NONE)
  public void m006() {}

  @Trace
  public void m007() {} // gets advised

}
</pre></code>
<p>Matching is currently allowed on all annotation value types *except* class and array. Also it is
not currently supported for parameter annotation values.

<h4>Changes since release candidate</h4>
<p>The only fix 1.6.0 final includes beyond the release candidate is a multi-threading problem in the weaver - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029">bug 227029</a>.

<h4>Releases leading up to AspectJ 1.6.0
<p>AspectJ v1.6.0rc1- 16 Apr 2008</p>
<p>AspectJ v1.6.0M2 - 26 Feb 2008</p>
<p>AspectJ v1.6.0M1 - 16 Jan 2008</p>
<hr>

</body> 
</html>