Rickard doesn’t understand why people want to use attributes for AOP
In a current blog of Rickard talks about the idea of using metadata attributes in order to assign pointcuts to code. He then goes on to say that he doesn’t like marking up the code with attributes and instead suggests using pointcuts to insert attributes and then write aspects against them.
The problem with this is that it is no different than making named pointcuts in AspectJ and has nothing to do with attributes and solves none of the problems that attributes solve. The reason people are interested in using attributes is to ensure that only those methods that are intended to be targeted by an aspect are actually targeted by an aspect. Let’s use his example:
<pointcut methods=”set*”>
<attribute name=”write”>true</attribute>
</pointcut>
<pointcut attribute=”write”>
<interceptor class=”StoreToDb”/>
</pointcut>
So then lets say that we have a class:
public class Foo {
public void setBar() {…}
public void settle() {…}
}
In his case, both of these methods would get assigned the interceptor “StoreToDb” when we really only wanted setFoo() to get this assigned. Even if someone checked when they originally wrote the aspect that it was only targeting the methods intended someone who has no knowledge of the pointcuts could come in later and add a method that was matched but not intended to be. That is just the limitation of text processing. We basically have a few choices in this case, either choose specific methods in our pointcut, add a rules engine to the AOP framework that can query code more intelligently, or we can use attributes to single out pointcuts in a predictable manner.
<pointcut methods=”setFoo”>
<interceptor class=”StoreToDb”/>
</pointcut>
or
<pointcut methodQuery=”select methods from * where method.name like ‘set%’ and method.arguments=1 and method.returns=”void” and method.mutates=”true” and there is another method get% that blah blah blah”>
<interceptor class=”StoreToDb”/>
</pointcut>
or
<pointcut attribute=”write”>
<interceptor class=”StoreToDb”/>
</pointcut>
One of the things I have been lobbying for with AOP and Java is to step back from the problem a bit and make sure that we are doing things properly. I think it is obvious to everyone that using regular expressions to match things in code is a bad idea. And if you don’t think its a bad idea, I’m not sure you understand the kinds of things that could happen given an errant method name with different semantics than what you expect. What I would like to see in the Java AOP world are a couple of things that we can build on and decide what should go into the general programming language and what should be left to system programmers. Ideally I think it should look like:
1) A low level meta programming API that can manipulate Java on a bytecode level.
2) A query API for intelligently choosing objects from the meta programming API.
3) An aspect oriented programming framework that only exposes functionality that is strongly typed (aka predictable).
When I say strongly typed, I mean that it will only provide pointcuts that are predictable. Having pointcuts match method and field names is a bastardization of a strongly typed language like Java. It may be acceptable in a more dynamic language, but for Java it changes the rules a bit too much. People may argue that AOP would not be powerful enough for them to write their containers, and I think that might be true, but those people would use the low level API. Right now it is too easy to inadvertently crosscut unintended pointcuts.
