Each piece of advice is of the form

[ strictfp ] AdviceSpec [ throws TypeList ] : Pointcut { Body }

and where Formal refers to a variable binding like those used for method parameters, of the form Type Variable-Name, and Formals refers to a comma-delimited list of Formal.

Advice defines crosscutting behavior. It is defined in terms of pointcuts. The code of a piece of advice runs at every join point picked out by its pointcut. Exactly how the code runs depends on the kind of advice.

AspectJ supports three kinds of advice. The kind of advice determines how it interacts with the join points it is defined over. Thus AspectJ divides advice into that which runs before its join points, that which runs after its join points, and that which runs in place of (or "around") its join points.

While before advice is relatively unproblematic, there can be three interpretations of after advice: After the execution of a join point completes normally, after it throws an exception, or after it does either one. AspectJ allows after advice for any of these situations.

  aspect A {
      pointcut publicCall(): call(public Object *(..));
      after() returning (Object o): publicCall() {
	  System.out.println("Returned normally with " + o);
      }
      after() throwing (Exception e): publicCall() {
	  System.out.println("Threw an exception: " + e);
      }
      after(): publicCall(){
	  System.out.println("Returned or threw an Exception");
      }
  }

After returning advice may not care about its returned object, in which case it may be written

  after() returning: call(public Object *(..)) {
      System.out.println("Returned normally");
  }

If after returning does expose its returned object, then the type of the parameter is considered to be an instanceof-like constraint on the advice: it will run only when the return value is of the appropriate type.

A value is of the appropriate type if it would be assignable to a variable of that type, in the Java sense. That is, a byte value is assignable to a short parameter but not vice-versa, an int is assignable to a float parameter, boolean values are only assignable to boolean parameters, and reference types work by instanceof.

There are two special cases: If the exposed value is typed to Object, then the advice is not constrained by that type: the actual return value is converted to an object type for the body of the advice: int values are represented as java.lang.Integer objects, etc, and no value (from void methods, for example) is represented as null.

Secondly, the null value is assignable to a parameter T if the join point could return something of type T.

Around advice runs in place of the join point it operates over, rather than before or after it. Because around is allowed to return a value, it must be declared with a return type, like a method.

Thus, a simple use of around advice is to make a particular method constant:

  aspect A {
      int around(): call(int C.foo()) {
	  return 3;
      }
  }

Within the body of around advice, though, the computation of the original join point can be executed with the special syntax

  proceed( ... )

The proceed form takes as arguments the context exposed by the around's pointcut, and returns whatever the around is declared to return. So the following around advice will double the second argument to foo whenever it is called, and then halve its result:

  aspect A {
      int around(int i): call(int C.foo(Object, int)) && args(i) {
	  int newi = proceed(i*2)
	  return newi/2;
      }
  }

If the return value of around advice is typed to Object, then the result of proceed is converted to an object representation, even if it is originally a primitive value. And when the advice returns an Object value, that value is converted back to whatever representation it was originally. So another way to write the doubling and halving advice is:

  aspect A {
      Object around(int i): call(int C.foo(Object, int)) && args(i) {
	  Integer newi = (Integer) proceed(i*2)
	  return new Integer(newi.intValue() / 2);
      }
  }

Any occurence of proceed(..) within the body of around advice is treated as the special proceed form (even if the aspect defines a method named proceed), unless a target other than the aspect instance is specified as the recipient of the call. For example, in the following program the first call to proceed will be treated as a method call to the ICanProceed instance, whereas the second call to proceed is treated as the special proceed form.

  aspect A {
     Object around(ICanProceed canProceed) : execution(* *(..)) && this(canProceed) {
        canProceed.proceed();         // a method call
        return proceed(canProceed);   // the special proceed form
     }
     
     private Object proceed(ICanProceed canProceed) {
        // this method cannot be called from inside the body of around advice in
        // the aspect
     }
  }	

In all kinds of advice, the parameters of the advice behave exactly like method parameters. In particular, assigning to any parameter affects only the value of the parameter, not the value that it came from. This means that

  aspect A {
      after() returning (int i): call(int C.foo()) {
	  i = i * 2;
      }
  }

will not double the returned value of the advice. Rather, it will double the local parameter. Changing the values of parameters or return values of join points can be done by using around advice.

With proceed(..) it is possible to change the values used by less-precedent advice and the underlying join point by supplying different values for the variables. For example, this aspect replaces the string bound to s in the named pointcut privateData:

  aspect A {
    Object around(String s): MyPointcuts.privateData(s) {
      return proceed("private data");
    }
  }

If you replace an argument to proceed(..), you can cause a ClassCastException at runtime when the argument refers to a supertype of the actual type and you do not supply a reference of the actual type. In the following aspect, the around advice replaces the declared target List with an ArrayList. This is valid code at compile-time since the types match.

  import java.util.*;

  aspect A {
    Object around(List list): call(* List+.*()) && target(list) {
      return proceed(new ArrayList());
    }
  }

But imagine a simple program where the actual target is LinkedList. In this case, the advice would cause a ClassCastException at runtime, and peek() is not declared in ArrayList.

  public class Test {
    public static void main(String[] args) {
      new LinkedList().peek();
    }
  }

The ClassCastException can occur even in situations where it appears to be unnecessary, e.g., if the program is changed to call size(), declared in List:

  public class Test {
    public static void main(String[] args) {
      new LinkedList().size();
    }
  }

There will still be a ClassCastException because it is impossible to prove that there won't be a runtime binary-compatible change in the hierarchy of LinkedList or some other advice on the join point that requires a LinkedList.

  import java.io.FileNotFoundException;

  class C {
      int i;

      int getI() { return i; }
  }

  aspect A {
      before(): get(int C.i) {
	  throw new FileNotFoundException();
      }
      before() throws FileNotFoundException: get(int C.i) {
	  throw new FileNotFoundException();
      }
  }

  aspect A {
      before(): execution(void main(String[] args)) {}
      after():  execution(void main(String[] args)) {}
      before(): execution(void main(String[] args)) {}
  }

  pointcut publicCall(): call(public * *(..));