[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Doc bug/clarification? (And why is it an implementation limitation?)

Wes,

Thanks for drawing this up. You're right, the docs have needed this for a while. I'm sure there will be a few new entries with AspectJ 5, but this (I think!) covers 1.2.x.

The language caveats aren't earth-shakingly critical, but they seem worth noting. You could easily have a section like "implementation notes" that mentions them but states that they are neither implementation limitations (implying they should be fixed) nor language limitations (implying they never can be).


Cheers,

Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming
m: 520 591-1849

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv
On Jan 10, 2005, at 12:37 PM, Wes Isberg wrote:

Hi -

Regarding the doc recommendation, we've needed a summary for a while so
readers in a pinch don't have to parse our carefully-worded prose. So,
below is what I'll add, modulo feedback. I've tentatively included some
language caveats as well, to raise the perennial question whether they
are language or implementation issues and which such caveats belong.
Absent comments, I'll leave the language caveats out; I think the list
should be complete (and have cross-references) to be useful.


Let me know what you think.
Wes

Summary of implementation limitations

* Requires the calling/invoking code
  o call join point
  o get join point
  o set join point

* Requires the defining/target code
  o execution join point
  o adviceexecution join point
  o handler join point
  o initialization join point
  o preinitialiaztion join point
  o staticinitialization join point
  o perthis aspect
  o pertarget aspect
  o declare parents
  o declare method or field (see interface caveats below)

* Implementation Caveats
o initialization and preinitialization join points do not support around advice
o handler join point does not support...
+ after advice
+ around advice
+ cflow(handler(..))
o Declaring members on an interface affects only the topmost implementing
classes the implementation controls.
o cflow and cflowbelow are limited in scope to a single thread.


* Language Caveats
o When declaring members in an aspect, only public members are accessible
to other clients. Package-private members are not accessible to subtypes
of the target types even if they are in the same package as the target
type or aspect.
o The order of evaluation of elements in a pointcut is undefined
(e.g., when evaluating if(..) pointcuts).


------------Original Message------------
From: Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Sun, Jan-9-2005 3:06 PM
Subject: [aspectj-users] Doc bug/clarification? (And why is it an implementation limitation?)


Hi,

I crashed into the "pertarget implementation limitation" today and I
was wondering if it couldn't be made a little clearer in the docs.
Although, on third read, the docs do indicate that pertarget won't work


on objects you don't control, it isn't intuitive that it should work
that way and the one sentence "Similar restrictions apply to pertarget
aspects." is easy to miss. I suggest that the paragraph be replaced:

original:
<<
Aspects that are defined perthis or pertarget also have restrictions


based on control of the code. In particular, at a join point where the

bytecode for the currently executing object is not available, an
aspect defined perthis of that join point will not be associated. So
aspects defined perthis(Object) will not create aspect instances for
every object unless Objectis part of the compile. Similar restrictions


apply to pertarget aspects.


suggested:
<<
Aspects that are defined perthis or pertarget also have restrictions
based on control of the code. In particular, at a join point where the


bytecode for the currently executing object is not available, an
aspect defined perthis of that join point will not be associated.
Similarly, at a join point where the bytecode for the target object is
not available, an aspect defined pertarget of that join point will not
be associated. So an aspect defined perthis(this(Object)) will not
create aspect instances for every object unless Object is part of the


compile. Similarly, an aspect defined pertarget(target(InputStream))
will not create aspect instances unless the bytecode for InputStream is


woven into.


I think this is clearer because I'm used to thinking of this() and
execution() as vulnerable to code control limitations but call() and
target() as being more robust. (yes, I know that's a simplification...)


Since pertarget() is implemented by weaving into the potential target
objects, it behaves a little differently than a call() && target()
pair.

Also, is it possible or advisable to allow a fallback implementation
strategy that uses a hashmap association (*) between an aspect and a
target when the target is not exposed to the weaver? Are there any
obvious problems with that?

Oh, and if we can't have the fallback strategy, could we instead have a

warning that says something like: "no potential targets detected for
this pertarget declaration (implementation limitation)". Since the
weaver must decide which targets to weave into, it must be able to know


if there aren't any.

* And by hashmap I obviously mean weak-reference/identity/threadsafe
hashmap

Cheers,

Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming
m: 520 591-1849

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

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