| Re: [aspectj-dev] is there a algorithm to compute whether two different pointcut expressions can share a join point? |
Actually, this problem is different from the issue the pointcut doc try to resolve. We want to know whether two pointcut select one common join point independent of the application (of course, we should know the necessary information referred in pointcut, but we don’t need the shadow information). That is to say, we care about the shared join point’s existence, instead of judging whether a concrete shadow belongs to both pointcuts.
Current shared join point identification techniques usually presume the existence of shadow. But on some level, we can give a conclusion that two pointcuts won’t share a join point without any shadow information. For example, we can tell that the following two pointcuts share no jointpoint.
call( boolean java.util.Iterator.hasNext(..) )
call(Object java.util.Iterator.next()).
We made this conclusion without some methods ( hasNext() or next()) actually called in some application.
The abc project (eric is familiar) actually implements a unify method for PointCut class. It implements the function I want, but it does not seem finish the whole work .
Unfortunately, the pointcut doctor is not compatible with the latest
versions of AJDT and AspectJ, but we are considering reviving the
project in the next release cycle (depending on how many other
requirements come in).
On Fri, Jul 2, 2010 at 11:56 PM, Eric Bodden
<bodden@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi.
>
> Have you looked at pointcut doctor? If I remember correcty, it does
> what you propose:
> http://pointcutdoctor.sourceforge.net/
>
> Eric
>
> --
> Dr. Eric Bodden
> Software Technology Group, Technische Universität Darmstadt, Germany
> Tel: +49 6151 16-5478 Fax: +49 6151 16-5410
> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>
>
>
> On 2 July 2010 20:05, Sandy Zhang <nudt.zhangxian@xxxxxxxxx> wrote:
>> Hi guys, is there a algorithm to compute whether two different pointcut
>> expressions can share a join point ?
>>
>> For example, we know these following two pointcut expressions may share a
>> join point.
>>
>> call( Object java.util.Iterator.*(..) );
>>
>> call( * java.util.Iterator.next(..) );
>>
>>
>>
>> While these two pointcut expressions definitely won’t share a join point
>>
>> call( boolean java.util.Iterator.hasNext(..) )
>>
>> call(Object java.util.Iterator.next())
>>
>>
>>
>> It first seems that the unification algorithm used in prolog can resolve
>> this problem. But the cflow operator changes this as the cflow( call(boolean
>> java.util.Iterator.hasNext(..)) ) and cflow( call( boolean
>> java.util.Iterator.hasNext(..) ) ) maybe share a join point. If we drop the
>> cflow operator, can the unification solve this issue?
>>
>>
>>
>> Maybe this thing seems meaningless to aspectj as the compiler only compiles
>> concrete code. And it is easy to find a shared join point in concrete code.
>> But it maybe a good hint to notify that the user writes a wrong pointcut as
>> it does not select any join point no matter what the code is. For example,
>> the pointcut:
>>
>> call( boolean java.util.Iterator.hasNext(..) ) && call(Object
>> java.util.Iterator.next()).
>>
>>
>>
>> If we cannot find an algorithm to resolve this problem given the complexity
>> of pointcut, is there a subset of pointcut operators which we can handle?
>>
>> --
>> Best regards,
>>
>> Xian Zhang
>>
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>>
>>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev