Re: [aspectj-users] AspectJ and JBoss AOP implementation

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

I was thinking of the same example, although this is really an implementation limitation of the bytecode weaving toolset from 1.1+ (as the compiler says) and not an AspectJ limitation. This restriction isn't necessary in an AspectJ implementation (indeed the 1.0.x source-based one didn't have it).

Ron Bodkin
Chief Technology Officer
New Aspects of Software
m: (415) 509-2895

> ------------Original Message------------
> From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Date: Thu, Jan-29-2004 10:05 PM
> Subject: Re: [aspectj-users] AspectJ and JBoss AOP implementation
> 
> To take an interesting (and well known/documented) example of non
> orthogonality from AspectJ itself, after and around advice cannot be applied
> to handler join points. A quick review of the mailing list reveals that this
> example of non-orthogonality causes confusion among programmers and a loss
> of robustness when broadly-defined pointcuts (tracing?) trip over this
> restriction.
> 
> I don't mean this as a criticism of AspectJ, because I'm aware of the
> problems with detecting the end of handler blocks. But it is a good example
> of the drawbacks Gregor cites.
> 
> Cheers,
> Nick
> 
> 
> On 1/28/04 3:25 PM, "Gregor Kiczales" <gregor@xxxxxxxxx> wrote:
> 
> > 
> >> Elizabeth Echlin Harmer  said:
> > 
> >> Could you explain what you mean by 'orthogonality
> >> of join point models'?
> > 
> > 
> >> Yes, because as I suggested, I believe this is one of
> >> the crucial properties of AspectJ, and a criteria for
> >> any AOP tool to scale.
> > 
> > With respect to pointcuts and advice, the model is orthogonal if:
> > 
> > - you can use any kind of advice on any join point
> > - you can write any kind of pointcut in any advice declaration
> > - you can compose any two pointcuts
> > 
> > Now it may be the case that two kind of pointcuts compose, but always
> > produce a null result, for example call(...) && execution(...). That's
> > OK, they still can be composed in the sense that the result is well
> > defined.
> > 
> > This notion of orthogonality is critical from a practical point of
> > view. Without it pointcut and advice code is very brittle.
> > 
> > Consider what happens if I write a public pointcut in one aspect. say
> > pointcut aquireResource(): ..., and then I use that pointcut in several
> > other places. You'd like your code to still work if I edit the
> > aquireResource pointcut, as long as within the domain sematics, the join
> > points it identifies really are points where the resource is aquired.
> > You'd hate for it to be the case that the code breaks if I happen to
> > use a different pointcut construct somewhere in the new definition of
> > aquireResource.
> > 
> > In that sense orthogonality has a real practical impact -- it makes the
> > code robust.
> > 
> > Orthogonality also makes an AOP tool easier to learn and use. In the
> > AspectJ model, where pointcut, join point and advice are three clearly
> > different and clearly orthogonal concepts, you can understand the language
> > in simpler terms.
> > 
> > - If Njp, Nptc and Nadv are the number of different kinds of join point,
> >   pointcut and advice respectively.
> > 
> > - Then in an orthogonal model, the complexity of understanding the
> >   language is something like Njp + Npc + Nadv.
> > 
> > - In a non-orthogonal model the complexity of understanding the language
> >   is something like Njp*Nptc*Nadv.
> > 
> > That's because in the orthogonal model I can, for example, reason about the
> > different kinds of advice, knowing that they each work similarly with all
> > kinds of join points. In a non-orthogonal language I have to remember that
> > this particular kind of advice only works with these particular kinds of
> > pointcut and those kinds of join point. My mental model is much more complex.
> > 
> > I've described this just in terms of the pointcut and advice join point
> > model. But the same holds for other join point models. For example AspectJ's
> > introduction and type pattern facility is join point model. The points are
> > effectively declarations, the pointcuts are the type patterns.
> > 
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> 
> -- 
> Nicholas Lesiecki
> Software Craftsman, specializing in J2EE,
> Agile Methods, and aspect-oriented programming
> 
> Check out my books:
> * Mastering AspectJ: http://tinyurl.com/66vf
> * Java Tools for Extreme Programming: http://tinyurl.com/66vt
> 
> Check out my articles on AspectJ:
> * http://tinyurl.com/66vu and http://tinyurl.com/66vv
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> 
>