org.aspectj/docs/release/README-1.6.0.adoc

= AspectJ 1.6.0

_© Copyright 2008 Contributors. All rights reserved._

== AspectJ v1.6.0 - 23 Apr 2008

For the complete list of every issue addressed since the last full
release, see
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].

Some of the highlights of 1.6.0 are:

=== Upgrade to a Java 1.6 compiler

AspectJ1.6.0 upgrades the internal Eclipse compiler level to version
785_R33x - a Java 1.6 level compiler

=== Better incremental compilation support in the IDE

Changes under https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[bug
221427] 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
https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html[this
mailing list post].

=== Parameter annotation matching

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.

[source, java]
....
execution(* *(@A *));
....

- Execution of a method/ctor whose first parameter is of a type
annotated with @A.

[source, java]
....
execution(* *(@A (*)));
....

- Execution of a method/ctor whose first parameter is annotated with @A

[source, java]
....
execution(* *(@A (@B *)))
....

- Execution of a method/ctor whose first parameter is annotated with @A
and is of a type annotated with @B. Example:

[source, java]
....
// ------ 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 -----
....

[source, text]
....
$ 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)
....

The first piece of advice matched both methods. The second only matched `goo()`.

=== Annotation Value Matching

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:

[source, java]
....
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

}
....

Matching is currently allowed on all annotation value types *except*
class and array. Also it is not currently supported for parameter
annotation values.

=== Changes since release candidate

The only fix 1.6.0 final includes beyond the release candidate is a
multi-threading problem in the weaver -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029[bug 227029].

=== Releases leading up to AspectJ 1.6.0

AspectJ v1.6.0rc1- 16 Apr 2008

AspectJ v1.6.0M2 - 26 Feb 2008

AspectJ v1.6.0M1 - 16 Jan 2008

'''''