[aosd-discuss] Re: motivation for call vs execution pointcut/join point distinction

[Renaud Pawlak]

Hi Alexandre,

I am not sure I understand all you say here. But the synchronization 
mecanism of Java is an old design and can definitly cause trouble for 
aspects.

To me, synchronization should be managed by an aspect which would fall 
into the same programming rules as the ones I scketched in my previous 
email: cflow+execution.

The parametrization of the synchronization aspect should probably be 
done by Java 5 annotations, which would make the synchronized keyword 
obsolete.

Of course, this would be in a ideal world :)

Cheers,
/Renaud

Alexandre Vasseur wrote:

> Thanks
> 
> I could find some little motivations for execution when it came to
> advising a "synchronized" method at first. Execution side advice will
> execute with the instance having the lock.
> But from a Java semantic standpoint the following is said to be
> strictly equivalent:
> 
> synchronized void func() {
>   // ...
> }
> void func() {
>    synchronized(this) {
>      //..
>    }
> }
> and obviously such a refactoring would change the advice synchronize
> semantic for the execution joinpoint. That could be seen as a weakness
> of the execution pointcut precisely because it may introduce a point
> that actually does not exist in the underlying execution environment
> (though it seems to exist when looking at source artifacts or
> compilation artifacts).
> 
> I am looking for use cases where ones would actually need execution
> join point of Foo.foo() under the assumption that the system can
> efficiently advise any call (or lets say "dispatch") to Foo.foo().
>>From the scenario given so far (changing the target, proceeding in a
> new thread), execution join point sounds like a limited case of call.
> Aside, proceeding in a new thread can actually be done in the middle
> of an advice dispatch (so called advice execution) chain.
> 
> Though I did implement (several times evolving with product/weaver
> versions) execution and call join point logic and pointcut matching in
> AspectWerkz, I am still not sure this concept is not an heritage from
> the way we see and do the weaving (ie source code / bytecode based).
> Alex
> 
> 
> 
> 
> On Apr 12, 2005 1:21 AM, Michael Schuerig <michael at schuerig.de> wrote:
> 
>>On Monday 11 April 2005 22:24, Alexandre Vasseur wrote:
>>
>>>Thoughts ? I would also welcome any link or paper on that.
>>
>>I've wondered the same a couple of weeks ago. See the discussion
>>starting at
>>
>>http://aosd.net/pipermail/discuss_aosd.net/2005-January/001322.html
>>
>></delurk>
>>
>>Michael
>>
>>--
>>Michael Schuerig                           The more it stays the same,
>>mailto:michael at schuerig.de                        The less it changes!
>>http://www.schuerig.de/michael/      --Spinal Tap, The Majesty of Rock
>>
>>__________________________________________________
>>AOSD Discuss mailing list    -    discuss at aosd.net
>>To unsubscribe go to http://aosd.net
>>
> 
> 
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
> 
> 


-- 
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - Bâtiment M3
59655 Villeneuve d'Ascq Cédex - FRANCE
Phone:  (+33) 328 778579
Cell:   (+33) 662 001919
Fax:    (+33) 328 778537
Emails: renaud.pawlak at inria.fr / pawlak at lifl.fr
WWW:    http://www.lifl.fr/~pawlak