Aspect-Oriented Programming with AspectJ

Verity Stob writes "There is a turning point in the emergence of a programming methodology. It doesn't matter how big and popular the website is, nor how many papers have been published in the ACM journals or development magazines, nor even whether the first conferences have been a sell-out. A methodology hasn't made really made it until somebody has published a Proper Book. With Aspect-Oriented Programming with AspectJ author Ivan Kiselev is bidding to drag AOP into the mainstream. He is motivated, he says in his introduction, by the recollection of the 25 odd years it took for the object-oriented concept to spread from its Simula origins in frosty Norway to being the everyday tool of Joe Coder. He aims to prevent this delay happening to AOP." Read on for Verity Stob's review of Kiselev's book. Aspect-Oriented Programming with AspectJ author Ivan Kiselev pages 274 publisher SAMS rating Excellent reviewer Verity Stob ISBN 0672324105 summary Introduction to a new programming technique using an extension to Java

He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.

AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:

package intro;

import java.io.*;

public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}

Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.

In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.

The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.

For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.

In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.

Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?

For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.

A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.

And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.

You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

So, what is this?

[Juiblex]

What is Aspect-Oriented Programming?? I've never heard of it!

Re:So, what is this?

[Caoch93]

Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?

It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.

Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.

Re:So, what is this?

[Anonymous Coward]

It reminds me a lot of the programming languages used for creating "interactive fiction" or "text adventure" games. Specifically Inform and TADS.

Game and simulation programming lends itself perfectly to aspect oriented design because it's full of objects and events which must be responded to. For example a "banana" object might have a "before eating" action which checks that the banana has been peeled and an "after eating" action in which it removes itself from the player's possessions and places a "banana peel" object there instead. A "monkey" object, might have an "after player enters room" action in which it attempts to steal the banana from the player. Since there are an unlimited number of possible events, it is impractical have a virtual function for each of them, so aspect-oriented programming is the only viable solution (especially if you want to create extensible libraries).

Re:So, what is this?

[Minna Kirai]

The "delegation pattern" may be somewhat similar, but because it's a "pattern"- a repetitive process that a programmer does again and again- it's still bad.

There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.

You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.

Re:So, what is this?

[ergo98]

While hardly the same thing, at the binary level this reminds me of Detours, a very cool binary interception package from Microsoft Research: Without the sourcecode it allows you to target and intercept calls at the function level, useful, for instance, for timing the framerate of an OpenGL application for instance (I wanted to know the effects of various settings so I intercepted the flip/render command in the opengl system calls...voila I had an exact timing of every frame interval). Of course this is much less of a scope, but it is a tremendously useful little tool.

Re:So, what is this?

[Anonymous Coward]

i won't argue the value of reducing the local complexity of code. however i fail to see how this differs significantly from structured or component-based programming where the logging logic is self-contained and called where necessary as a simple yet well-conceived interface. this is 25 year old technology that is as clean (and reusable) as anything ever written.

if the purpose of AOP is to remove the actual logging calls from the data module you wouldn't be doing any logging i suspect. unless the calls were stealthily inserted by a preprocessor or some other tool. which isn't good either because then you can't tell whats really going on.

pick a methodology and stick with it, not for a few months, try a decade. if its really that good its worth hanging onto.

Re:So, what is this?

[mvw]

Dijkstra's criteria for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded

Bounded and large would be worse enough. Let me rather cite:

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.

Regards,
Marc

Re:So, what is this?

[Samrobb]

A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.

That's a true statement about any program. Just try tossing in a random uninitialized pointer or runtime exception here or there in any utility function, rebuild, and see what happens.

I've written "aspect"-like code before... a system that I worked on not too long ago (hey, Honus!) made use of a pretty nice set of functions and macros in order to:

• trace function call entry
• do parameter checking
• log return values
• log exceptions/unexpected return values

This involved manually adding the appropriate macro at the start and end of each function. A pain in the butt, and the inevitable tyop came back to bite you hard :-/ IMHO, this is the type of problem that aspect oriented programming is intended to solve.

Yah, improperly coding an aspect could cause all sorts of heartache and difficult to solve problems. But... when we did the same thing by hand, it still caused heartache and difficult to solve problems. I'll take AOP (supported by an AOP-aware debugger) over doing this sort of thing by hand any day of the week.

Where's this useful?

[KiahZero]

I honestly don't understand the applications for this. Maybe it's just because I'm reading the review rather than the actual book, but it does'nt feel all that useful.

I can understand the benefits of OOP over standard top-down programming, but I'm failing to see where this coding methology gives you any gains.

Re:Where's this useful?

[Lord of the Fries]

The common examples seem to be persistance, concurrency, and something else. AOP is OK, my problem though is that its applicability to orthogonal issues seems (to me) limited. I am rarely able to find any more uses than the common three examples. I am much more interested in some of the recent work done on Traits Programming.

Re:Where's this useful?

[cushty]

The other is probably design by contract or something like that. Checking that things that call a method pass good parameters and that methods return what they say they should. A generic aspect could check that all parameters are not null and that a method doesn't return null. A more specific aspect could check particular method parameters, return values, and object consistency. Once confirmed to be working you remove the aspects and your code will "just work like normal" *gulp*

Re:Where's this useful?

[Caoch93]

Really, the biggest use for AOP is, as far as I know, still not available in AspectJ. AspectJ was, as of the last time I looked at it, just an additional compiler for a language extension to Java. As a result, I can't say that I find AspectJ all that amazing.

AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.

The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.

This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.

Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.

It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.

Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.

Then again...I could be talking arse. Here come the flames!

Re:Where's this useful?

[Minna Kirai]

Seems in a large project it would be real easy to forget about code that executes that you cant see.

The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.

Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.

In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.

Re:Where's this useful?

[asolipsist]

I still dont understand how this is all that much different than event driven programming. Obviously its syntatically different than using event triggers, but is it conceptually?

Every example of AOP I've seen uses the "logging example" (is AOP actually useful for anything else?)
In this example some sysout is printed after certain method calls.
methodFoo();
methodBar();
both trigger message();

so what? Can't this be done with java style event handlers and triggers? Are there benefits of AOP beyond oberserver/oberserved type relationships?

Hasn't CLOS had this sort of thing (15 years ago)

[helixcode123]

This sounds similar to the Common Lisp Object System (CLOS) :before and :after methods.
If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.

Re:Hasn't CLOS had this sort of thing (15 years ag

[iggymanz]

Yes, and languages like SmallTalk and Ruby also allow similar constructs.....the one advantage I can see from looking at the AO extensions to Java is perhaps a little more clarity in being able to quickly see the melds between methods of disparate classes, but the functionality is no different.

I did see a project on sourceforge to add explicit AOP to Ruby, perhapss making code more understandable, but of course one can hook methods without it

Books

[alext]

A methodology hasn't made really made it until somebody has published a Proper Book.

What, like The Art of the Meta-Object Protocol by the very same Gregor Kiczales et al, pub. MIT Press, 1991?

Like most things, AOP is only new if you don't know LISP. :-)

AOP is useful, but not well suited to Java

[kahei]

I think the reason there are so many 'huh? why do I want to do all this?' responses is that Java is not a language that lends itself to AOP, and that AspectJ therefore has to build this scary layer of 'pointcuts' and so on on top of it.

With a language that lets you assembly types dynamically, like Ruby or Perl, AOP is much simpler and more natural, so it's easier to get a feel for the benefits.

In particular I think Ruby is well-suited, although you do lose some type safety. There is a package called AspectR available, although you *could* do it all youself with mixins and the like.

I bought it - its worthless!

[NovaX]

I bought it back in january, after first learning about AOP. At the time, it was the only book I could find directly on AOP, with a second coming in feb. Otherwise, the only other text source I could find was Generitive Programming.

So I bought it, and I was excited when I began reading. Then I found out it was just a bunch of JSP and other then the first 25 pages, very little content. Now I admit I put it down a good 25 or so pages later and skimmed through the rest, but I was extremely disapointed in it. Instead I've been grabbing all of the ECOOP workshop documentation.

In the end, it was worth the money. No, not for the book, god no! But by getting me excited and reading the ACM Communication articles and then talking to my adviser about it. It turns out the editor for the AOP material in the ACM communications is a professor at my school, and even better is happy to let me help her out next semester (I'm extremely swamped now). So now I'm considering doing the thesis option on my masters. I'll spend the summer reading REAL material.

My opinion: AOP is awesome but the book is a waste of money. Here are a few good readings:

Alternatives to AOP
Generitive Programming chapter
AOP publication
AOD 2002 workshop
ECOOP97

Breaking encapsulation

[infinite undo]

Modularity, encapsulation, separation of concerns or whatever you want to call it is still a good idea.

Aspect Oriented Programming claims to support a new kind of modularity, but what it really does is break encapsulation.

Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.

If they had used your published interface and you designed a good interface, you would have been ok, but no! They reached into your code and created dependences on your implementation. If it's production code and you break someone else's code, you'll be seen as the bad guy.

Many years ago I used Xerox Lisp machines and worked near the inventors of Aspect Oriented Programming. I used two precursors of AOP. I used the advice mechanism in InterlispD and later Active Values in it's object oriented extension Loops.

When used very sparingly, advice was useful, especially for debugging and working around bugs. The advise function allowed you to add wrappers to functions that would replace, preceed or follow the invocation of the function. You could further restrict the advice to apply only when a function was called from within another function.

Active Values, on the other hand, were an advice mechanism applied to object field access. People quickly realized that the facility was a mess because there was rarely any hope that you could get your advice to run *only* when you wanted it to and rarely any hope that you could avoid a unreadable tangled mess. There were new getter and setter functions that didn't trigger the active values, but this just added even more complexity.

It would be much easier to design an explict hooks than to worry about what happens if someone sticks an active value in any and every object field. Especially when the field may already have an active value.

It's vital to be able to assume that when you read a line of code, you know what it means and if not, you know where to look up what it means. Rather than enabling hacks like aspect oriented programming, we need better tools for making clean changes that sweep across the source code and thereby do away with the urge for this perilous patching stratgy.

Why LISP is not mainstream...

[irritating environme]

LISP programs are practically always unreadable. If it's unreadable, it's unmaintainable. Look at how all algorithms are laid out in CS books: that's structured programming. They certainly don't do a step, and then have you turn to another page to do the next step, and turn to another page to do the next step.

(tail (make (get (blah (foo()), bar())))))

In the end, this lang vs. that lang is "fundamentally superior" is all bullshit since practically all languages are Turing equivalent, so practical acceptance comes down to ease of learning, readability, API and platform support, speed, and sensible amounts of syntactic sugar.

Java does all those things pretty well. LISP had 50 years to gain acceptance, and it hasn't. It has had numerous evangelizers, even whole tech startups, and all for naught.

Re:Yet another reason to switch to Lisp

[jcast]

That may be true, but it still would've been better if he'd make a bigger deal about the lisp roots of the thing. May help it ``escape the computer labs'' and all.

Re:Verity Stob

[a2800276]

Yep, can't believe nobody picked up on that. While Dr. Dobbs has a fair amount of weird ecclectic columns (Swaine, Campervan-jazz-musician-what's-his-name, etc.) Verity Stob is by far the best of them. One of my favourites is the lifecyle of the desktop PC: State of Decay (It's so true.)

Nicely written, informative book review, too, by the way. Hope we see more of her here!

Speaking of weird things to like about Dr. Dobbs, does anyone else look forward to the PC-Lint advert/riddles every month? -- Asking that feels strangely embarassing, similar to asking "Does anyone else ever find that they've been talking to themselves for the last hour with the office door open?" :-)

Re:Hasn't CLOS had this sort of thing (15 years ag

[sql*kitten]

If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.

Yes, and relational databases have had trigger methods before and after different SQL operations. You can define 12 triggers on a table in Oracle, made out of combinations of (before, after) (insert, update, delete) (for each row, for each statement). You code them in PL/SQL which is a fairly comprehensive language similar to Ada. Is AOP merely triggers for Java methods? Because you could do that already, by subclassing, overriding the method, and calling the superclass method within your own code.