[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?)

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
>