Comment 1 Andrew Clement 2009-03-07 12:14:48 EST

Can i ask how you were using the matcher?

Comment 2 Andrew Clement 2009-03-12 14:03:34 EDT

Putting notes from the email exchange in here otherwise they will be lost.

Bruno wants to use a reflection world - whereas the initial reason for extracting the matcher was with SpringAOP and an alternative world implementation.  Due to the module structure the weaver5 code (where the reflection world extensions for 1.5 support lives) is not included in the matcher jar file.  To do it properly I would need to split weaver5 into weaver5 and matcher5 (much like I split weaver to be matcher and weaver).  This isn't trivial.

There is a way to force the world to behave as a 1.4 world but the reflection support will not expose anything related to annotations or generics.  It is done by creating a ReflectionWorld and forcing the use of only 1.4 delegates:

new ReflectionWorld(boolean forceUseOf14Delegates, ClassLoader aClassLoader);

However, from Brunos basic scenario:

import org.aspectj.weaver.tools.PointcutParser;

public class Main {
       public static void main(String[] args) {
               PointcutParser parser = PointcutParser.getPointcutParserSupportingAllPrimitivesAndUsingContextClassloaderForResolution();
               parser.parsePointcutExpression("execution(* *(..))");
       }
}

There is no way to pass the world we want to use to that pointcut parser.  However, there is no documentation on correct use of the extracted matcher, there are only testcases, like this one:
http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/modules/org.aspectj.matcher/testsrc/org/aspectj/matcher/tools/CommonPointcutExpressionTests.java?revision=1.3&root=Tools_Project&view=markup

which show the way to get a parser using a world is via:
pointcutParser = StandardPointcutParser.getPointcutParserSupportingAllPrimitives(world);

I remarked to Bruno:

Andy said:
>>    [...] I will say the API around StandardPointcutExpression.matchesXXX are 
>> messy, and that is partly because they are only just starting to be
>> abstracted away from a version that just supported matching a reflection 
>> based representation of the join points.
>
> Bruno said:
> 
> The method I am proposing is precisely one way in which you could add an 
> interface that is less messy, by unifying the different XXX's as 
> org.aspectj.lang.JoinPoint. Although this may cause a dependency to
> aspectjrt.jar, and I could understand you don't want that.

I would rather not have a dependency on aspectjrt.jar and am actively trying to avoid it.  Due to other pressures that API will only change when necessary, I don't imagine I will have any time to fix it up for the next few months.  If you want to work on sorting it out and give me a patch, that would be great.  Otherwise we'll just have to cope with the current state it is in.

Your findings are very interesting as you are the first person to attempt to try it out - I think it proves that it is a long way from being finished.

Comment 3 Andrew Clement 2010-03-15 17:37:04 EDT

recommendation is to use the aspectjweaver.jar to solve this problem, instead of org.aspectj.matcher.jar (and so pickup the dependency).  Further matcher improvements are not imminent.  The original driving requirements from the IDE are now not so urgent.

However, since I wrote my previous comment AspectJ has now become a Java 5 project so it should be possible for org.aspectj.matcher.jar to easily include the missing type with a tweak to the build process (but that is something I don't want to tackle right now).