Simon Wacker

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.

How to name classes, packages, methods, …. . Everything needs a name. That’s the problem I’m facing every day and I think every programmer does. There seems to be no book that deals with that issue. Or at least I haven’t found one. So what does the internet hands over.
If you search on java.sun.com you’ll probably find the basic stuff like this: Code Conventions but isn’t there greater help out there?
A really helpful article I found next was on hacknot.info: Naming Classes - Do It Once And Do It Right.
And then I stumbled over a kind of ultimate guide: AmbySoft - Coding Standards For Java.
The articles are obviously good but they aren’t perfect now. I’d really appreciate a good book that only deals with the issues of naming. It shouldn’t define standards and say: “That’s the truth!” but reflect different possibilities and show the advantages as well as the disadvantages of each.
I hope such a book will be available for novice programmers some day.
Maybe I’ll write one myself.

I haven’t been blogging for four months now. But after these great experiences I made at the FlashInTheCan 2004 conference in Toronto, Canada, I really have to start all over again.
I actually handled (or I was helped) to meet up with all the boys and girls of the Flash scene like Vera Fleischer, Kai König, Grant Skinner, Guy Watson, LordAlex, Dave Yang, Sean Voisen and many many more I sadly cannot remember the name of. Sorry guys! If you are one of these leave me a note. I’d really like to keep the contact.
Without exaggerating I can say that I had the greatest time during these three days at the conference. It was outstanding. Even now I can’t really believe it. It’s still more like a dream than reality. THANK YOU ALL FOR THE GREAT TIME.

Okay let’s switch over to another theme. Over the past few months I worked together with the as2lib team quite hard on the as2lib and especially at the days in Toronto. We gonna make a big (and our first) release during the next few weeks. This update will include: Reflection (maybe you know it from Java), better Event, Exception and Output Handling and a lot more. As you can see, these classes focus mainly on the programming perspective. But in future releases there are also going to be things for designers like e.g. the VisibleObject classes etc. Thus, stay tuned.