An Overview of AspectJ Sabine Hauert

Today's Deserts  Whipped introduction served with its three berries syrup  Chocolate history soufflé  Design assumptions sunday with pecans  Language sorbet with a choice of the following flavors:  Join point madness  Too sophisticated point cuts  Advice for the mindless  Aspects with an attitude  Orange implementation fluffy mousse  Too good to dare conclusions

Introduction  What is AspectJ?  Aspect oriented programming (AOP) extension to Java

Introduction  What is AOP?  Separation of concerns  Modularity  No more tangled code  Simplicity  Maintainability  Reusability  Aspects  encapsulate behaviors that affect multiple classes (OO) into reusable modules.

Introduction  What is a crosscutting concern?  Behavior that cuts across the typical divisions of responsibility, such as logging or debugging  A problem which a program tries to solve.  Aspects of a program that do not relate to the core concerns directly, but which proper program execution nevertheless requires.

History  Developed at Xerox PARC (Palo Alto RC)  Launched in 1998  PARC transferred AspectJ to an openly- developed eclipse.org project in December of For more info:

Design assumptions  Real Community Users  Writing aspects  Reading aspects  Idioms  How effective for concerns  Modular,reusable and easy to develop and maintain  Java compatibility  Upward compatibility  Platform compatibility  Tool compatibility  Programmer Compatibility

Language Dynamic VS Static crosscutting  Dynamic crosscutting  define additional behavior to run at certain well-defined points in the execution of the program  Static crosscutting  modify the static structure of a program (e.g., adding new methods, implementing new interfaces, modifying the class hierarchy)

Language Join Points  Well-defined points in the execution of a program:  Method call, Method execution  Constructor call, Constructor execution  Static initializer execution  Object pre-initialization, Object initialization  Field reference, Field set  Handler execution  Advice execution

Language Join Points public class Point { private int x; private int y; public Point(int x, int y) { this.x = x; this.y = y; } public void incrXY(int dx, int dy){ x=+dx; y=+dy; } … } public class Test{ public static void main(String[] args) { Point pt1 = new Point(0,0); pt1.incrXY(3,6); } Method-execution “Test.main(..)” Staticinitialization “Point._clinit_” Constructor-call “Point(..)” Preinitialization “Point(..)” Initialization “Point(..)” Constructor-execution “Point(..)” Field-set “Point.x” Field-set “Point.y” Method-call “Point.incrXY(..)” Method-execution “Point.incrXY(..)” Field-set “Point.y” Field-set “Point.x”

Language Pointcuts  A set of join point, plus, optionally, some of the values in the execution context of those join points.  Can be composed using boolean operators ||, &&  Matched at runtime

Language Example

Language Pointcut examples call(public void Point.setX(int)) Matches if the join point is a method call with this signature. call(public void FigureElement.incrXY(int,int)) Matches if the join point is a method call to any kind of figure element. call(public void Point.setX(int))|| call(public void Point.setY(int)) Matches any call to setX OR setY !this(FigureElement)&& call(public void FigureElement.incrXY(int,int)) Matches all method calls to incrXY that come from an object of another type, as well as calls from static methods

Language User-defined pointcut desigantors. Pointcut moves(): call(void FigureElement.incrXY(int,int))|| call(void Line.setP1(Point)) || call(void Line.setP2(Point)) || call(void Point.setX(int)) || call(void Point.setY(int)) moves()

Language Advice  Method-like mechanism used to declare that certain code should execute at each of the join points in the pointcut.  Advice:  before  around  after  after returning  after throwing

Language Advice execution order Different tries have brought me to the conclusion that advice ordering is not as described in the paper. …eclipse example(Live demo).

Language Pointcut parameters and thisJoinPoint Parameters  Exposes certain values that are in the execution context of the join points. before(Point p, int nval): call(void Point.setX(int))&& target(p)&& args(nval){ if(nval>MAXBOUND) System.out.println(“The value is too big !”); else System.out.println(“x value of “+p+” will be set to : “+nval); }

Language Pointcut parameters and thisJoinPoint thisJoinPoint  Simple reflective access to information about the current join point. Notice that this is very useful for debugging and tracing purposes. before(): call(void Point.setX(int)){ if(((Integer)thisJoinPoint.getArgs()[0]).intValue()>10) System.out.println("The value is too big !"); else System.out.println("x value of ” +thisJoinPoint.getTarget() +" will be set to” +thisJoinPoint.getArgs()[0]); }

Language Wildcards and cflow  Wildcards  call( * Point. *(..))  call( public * com.xerox.scanner.*.*(..))  call( * Point.get*())

Language Wildcards and cflow  Control-flow  pointcut moveContext(): cflow(move())  picks out each join point that occurs in the dynamic context of the join points picked out by move().

Language Wildcards and cflow  Control-flow below pointcut moves(FigureElement fe): target(fe)&& …); pointcut topLevelMoves(FigureElement fe): target(fe)&& moves(FigureElement)&& !cflowbelow(moves(FigureElement)); before(FigureElement fe): target(fe)&& topLevelMoves(FigureElement) { System.out.println("top level moves"); }

Language Inheritance and Overriding of Advice and pointcuts  Abstract aspect & Abstract pointcuts abstract aspect SimpleTracing{ abstract pointcut tracePoints(); before(): tracePoints() { printMessage(“Entering”,thisJoinPoint); } after(): tracePoints(){ printMessage(“Exiting”,thisJoinPoint); } void printMessage(Stringwhen,JoinPoint jpt){ code to print an informative message using information from the joinpoint } }

Language Inheritance and Overriding of Advice and pointcuts  Concrete implementation of the aspect: aspect IncrXYTracing extends SimpleTracing{ pointcut tracePoints(): call(void FigureElement.incrXY(int, int)); }

Language Aspects  Mix everything we’ve seen up to now and put it one or more modular units called Aspects.  Looks a lot like a class!  Can contain pointcuts, advice declarations, methods, variables ….  Single instances (default behavior)

Language Aspects aspectMoveTracking { static boolean flag=false; static boolean testAndClear(){ boolean result =flag; flag =false; return result; } pointcut moves(): receptions(void FigureElement.incrXY(int,int))|| receptions(void Line.setP1(Point)) || receptions(void Line.setP2(Point)) || receptions(void Point.setX(int)) || receptions(void Point.setY(int)); after(): moves() { Flag =true; }

Language Ordering Aspects In order to control precedence between aspects use something like: declare precedence : Mobility, MoveTracking, * ; Where at each join point, advice from Mobility has precedence over advice from MoveTracking, which has precedence over other advice.

Language Ordering Aspects Example: aspect Mobility{ declare precedence Mobility, MoveTracking; private static booleanenableMoves =true; static voidenableMoves() {enableMoves =true; } static voiddisableMoves(){enableMoves=false;} around() returns void:MoveTracking.moves(){ if(enableMoves ){ proceed(); }

Implementation  Aspect weaving: makes sure that applicable advice runs at the appropriate join points.  In AspectJ, almost all the weaving is done at compile-time to expose errors and avoid runtime overhead.  Cflow and this (maybe others) require dynamic dispatch.

Demos  If there is enough time I can show a few interesting and simple AspectJ programs I have. Just to show off the eclipse environment.

Conclusion  Three words  Modular  Concise  Explicit  Questions  How big a problem is encapsulation?  When to use an aspect and when to refractor the code?  Are aspect realistic for big systems?  How does this compare to what has been seen before?  Criticisms on the language design?