Simon Wacker

We have already worked with kinded pointcuts in the examples of the previous posts. But I haven’t explicitly explained what different types of kinded pointcuts exist and which join points they exactly capture. Here’s a list of the kinded pointcuts AspectJ provides:

> execution(MethodSignature/ConstructorSignature):
As you have probably already imagined this will capture the method or constructor execution matching the signature.
> call(MethodSignature/ConstructorSignature):
Such a pointcut captures the calls to methods matching the signature.
> get(FieldSignature):
This pointcut will capture the retrieval of the value of a field matching the signature.
> set(FieldSignature):
This will capture the write access to a field matching the signature.
> handler(TypeSignature):
This will capture executions of exception handlers.

Examples:
call(public * MyClass.*())
This would capture all calls to all public methods in the class MyClass that do not take any arguments.

set(private float MyClass.myField)
This would capture write access to the private field myField of the class MyClass.

These are the most common pointcuts. There do also exist pointcuts to capture the Object initialization and pre-initialization and so forth. But I won’t show them here.

In the AOP examples I used in my previous posts I always captured exactly one join point with my pointcut. If you would always do it that way you had to define one pointcut for every join point. That is as you can probably imagine not effective. The real benefit comes then when you capture join points due to specific characteristics. For example you wanna capture every method in a specific class that throws an Exception. To do this you need wildcards.
AspectJ offers three wildcard notations:

- “+” indicates all subclasses or subinterfaces of a given type
- “..” indicates any number of charecters including all periods
- “*” indicates any number of characters excluding the period

You also have the negation operator “!” and the two operators “||” and “&&”.

Example:
public pointcut myPointcut() : execution(public * javax..*Model+.set*(*));

This would capture the execution of all public methods starting with set, taking one argument of any type, regardless of the return type that are defined in a class whose name ends with Model or any of its subclasses that reside in the javax package or any direct and indirect subpackages.

Funny … isn’t it?

I covered the basics of AOP in my previous articles “AOP - Aspect Oriented Programming” and “AOP: Terms and AspectJ”. If you haven’t read them yet I’d suggest you to do this now. Otherwise just go on reading.
As I mentioned earlier pointcuts capture or identify join points. Named poincuts have the following syntax:

Syntax:
[access-specifier] pointcut pointcut-name([arguments]) : pointcut-type(signature)

Example:
public pointcut myPointcut() : execution(public void MyClass.myMethod())

You do use them in an advice as follows:

before() : myPointcut() {
…
}

Anonymous pointcuts are directly declared behind the “:”. It would then look like this:

before() : execution(public void MyClass.myMethod()) {
…
}

Well, that’s it for now. Easy, isn’t it? I will cover wildcards in my next article about AOP. And I hope that at the latest then you will recognize that AOP is a lot of fun.

AspectJ is a programming language that enables you to write Aspect Oriented code for Java. The terms I’m going to explain in this article probably apply to every other Aspect Oriented language but I’m going to give examples in AspectJ code. Let’s start:

You describe with AspectJ where to weave in the crosscutting logic and what to weave in. To do this you need at first identifieable points called join points.

Join Point
“A join point is an identifiable point in the execution of a program”. A join point is quasi everything within your class. For example a call to a method, an assignment to an instance variable and so forth. These join points represent the places where the crosscutting logic can be woven in. Join points do reside in classes.

Example:
public class MyClass {
…
public void doSomething(int parameter) {
instanceVariable = parameter;
}
}

The join points in this class are the execution of the doSomething method as well as the assignment of the variable instanceVariable.

Aspect
The aspect is the main construct of your aspect code. You can compare it with a class although there are varieties.

Example:
public aspect MyAspect {
}

Pointcut
You somehow need to select a join point in your aspect. You do this with a pointcut.

Example:
execution(void MyClass.doSomething(int))

You now capture the execution of the doSomething() method in the class MyClass. But you also want to execute code when the execution takes place. Thus you need an advice.

Advice
“An Advice is the code to be executed at a join point that has been selected by a pointcut”. You have different opportunities when the execution shall take place: before, after or around the join point.

Example:
before() : execution(void MyClass.doSomething(int)) {
System.out.println(”The doSomething() method will be executed.”);
}

Example that sums everything up:
public class MyClass {
private int instanceVariable;
public void doSomething(int parameter) {
instanceVariable = parameter;
}
}

public aspect MyAspect {
before() : execution(void MyClass.doSomething(int)) {
System.out.println(”The doSomething() method will be executed.”);
}
}

If you now compile the aspect MyAspect the System.out.println() call will be woven into the code of the class MyClass. The result would decompiled probably look like the following:

public class MyClass {
private int instanceVariable;
public void doSomething(int parameter) {
System.out.println(”The doSomething() method will be executed.”);
instanceVariable = parameter;
}
}

Okay that are basics for now. The next article will go more in depth.

Aspect Oriented Programming is a methodology, like OOP, that has been around for a few years now. But it is sadly not as known as OOP. I myself came across it only a few weeks ago and I was fascinated by the whole idea. AOP targets mostly on the implementation of crosscutting concerns like logging and tries to seperate the whole crosscutting logic from your actual code. As far as I know it now is it not there to substitute OOP or other methodologies but to work with them hand in hand. The problem AOP faces is that it is something new and has first to be accepted in the community. The other issue is that you need a programming language that supports AOP like AspectJ for Java. Even though you could probably partly implement it with a “few” workarounds in a non-AOP language.
To show you what AOP is all about let’s look at the logging example. If you write a method that logs you probably do it the following way:

class YourClass {
public int doSomething() {
logger.log(”Before: execution(YourClass.doSomething())”);
…
logger.log(”After: executeion(YourClass.doSomething())”);
}
}
(Your log output maybe looks a little different.)

What’s wrong with this?
Well, wrong are the two calls of the logger.log() method before and after the execution of the doSomething() method because it has nothing to do with the primary thing the method tries to accomplish. The problem is that you cannot handle logging easily in a better way using just plain OOP. That’s the time when AOP comes in. To express it in code:

// the actual logic
class YourClass {
public int doSomething() {
…
}
}

// aspect “code” aspect YourAspect {
before execution of method doSomething() in class YourClass do the following: logger.log(”Before: execution(YourClass.doSomething())”);
after execution of method doSomething() in class YourClass do the following: logger.log(”After: execution(YourClass.doSomething())”);
}

If you’d now compile the aspect named YourAspect the aspect and the class would be woven together and you’d get the same result as in our first example.
This looks/sounds a little scary for the first time. Partly because it isn’t real code and maybe partly because it is something new and unknown and although partly because I’m not a good writer of examples and the above “code” is a little awkward written so don’t be scared. The cool thing is that your actual logic is now almost completely seperated from the logging code and you could just wipe off the whole logging code without modifying your actual logic.
That’s it for now. I hope you got the basic idea. But there is much more to come. So stay tuned.