[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] AspectJ and JBoss AOP implementation
|
The issues with handler join points go beyond the implementation limitation.
ajc-1.0 allowed after returning advice on handlers because it could detect
the end of a catch block reliably. However, after throwing and around
advice have never been allowed on handler join points. These kinds of
advice interact in interesting ways with the block structure of Java.
Here's a short example:
void m(boolean test) {
String s;
try {
if (test) throw new RuntimeException();
s = "no exception";
} catch(RuntimeException re) {
s = "caught exception";
}
System.out.println("s = " + s);
}
Java's static analysis can show us that s must be assigned before it is
printed either in the try block or in the catch block. Now, consider a
piece of around advice on that exception handler where the around doesn't
call proceed. In that case we would find that s has never been assigned by
the time it gets to the print statement. This breaks a very strong
guarantee of the Java language.
Currently, handler join points are the only ones that interact with Java's
block structure and have this problem. We've discussed adding join points
for when an exception is thrown (corresponding to the throw statement) and
for synchronization blocks. These join points would have the same problem.
Even if there were no implementation issues we may be forced to have some
join points that can only have around advice on them that is guaranteed to
call proceed at least (or maybe even exactly) once.
The main point of this message is to show that orthogonality can be much
harder to get right at both the design and implementation level than you may
suspect.
-Jim
> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
> admin@xxxxxxxxxxx] On Behalf Of Gregor Kiczales
> Sent: Friday, January 30, 2004 8:16 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] AspectJ and JBoss AOP implementation
>
> Indeed, this bit of non-orthogonality is a limitiation of the current
> AspectJ implementation. We know the design doesn't have it, because the
> 1.0 implementation didn't have it. What this shows of course is that
> achieving orthogonality isn't so simple, even once we got there, we had
> to (hopefully temporarily) retreat a little in 1.1.
>
> > -----Original Message-----
> > From: aspectj-users-admin@xxxxxxxxxxx
> > [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> > Sent: Friday, January 30, 2004 12:14 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] AspectJ and JBoss AOP implementation
> >
> >
> > 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
> > >
> > >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
