An Overview of AspectJ Sabine Hauert Today's Deserts     introduction served with its three berries syrup Chocolate history soufflé Design assumptions sunday with pecans Language sorbet.

Download Report

Transcript An Overview of AspectJ Sabine Hauert Today's Deserts     introduction served with its three berries syrup Chocolate history soufflé Design assumptions sunday with pecans Language sorbet.

An Overview of AspectJ
Sabine Hauert
Today's Deserts




introduction served with its three berries syrup
Chocolate history soufflé
Design assumptions sunday with pecans
Language sorbet with a choice of the following flavors:
Whipped
 Join point
madness
 Too sophisticated
 Advice


point cuts
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 openlydeveloped eclipse.org project in
December of 2002.
For more info: www.eclipse.org/aspectj
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
Method-execution
Constructor-call
Method-call
“Test.main(..)”
“Point(..)”
“Point.incrXY(..)”
Staticinitialization
“Point._clinit_”
Preinitialization
Initialization
Constructor-execution
Field-set
“Point(..)”
Field-set
“Point(..)”
“Point(..)”
“Point.x”
“Point.y”
Method-execution
Field-set
Field-set
“Point.incrXY(..)”
“Point.x”
“Point.y”
public class Test{
public static void main(String[] args) {
Point pt1 = new Point(0,0);
pt1.incrXY(3,6);
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;
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
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
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.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
moves()
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))
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
 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
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)&&
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
receptions(void
receptions(void
receptions(void
receptions(void
FigureElement.incrXY(int,int))||
Line.setP1(Point)) ||
Line.setP2(Point)) ||
Point.setX(int)) ||
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?