Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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



Back to the top