Community
Participate
Working Groups
Created attachment 108239 [details] sources for reproduce case Param annotation matching pointcut does not always match. I have an interface whose method parameter is annotated. Some implementations [of interface] match the pointcut but other implementations [of same interface] do not match. To reproduce: ------------- 1. Unpack attached sources 2. Clean AspectJ project + rebuild 3. Run "CC.main()". Test succeeds (pointcut matches) 4. Run "LongLong.main(). Test fails (pointcut doesn't match) Workaround: ----------- 5. Edit method "LongLong.m1()" immediately after rebuild. 6. Run "LongLong.main()". Test succeeds. My Eclipse environment is: -------------------------- Eclipse AspectJ Development Tools Version: 1.5.2.200804241330 AspectJ version: 1.6.0.20080423100000 Eclipse v3.3.2 M20080221-1800
investigate for 1.6.2 - might already have been fixed in 1.6.1 (AJDT 1.5.3)
No, not already fixed, and it is a problem due to pipeline compilation. I suspect I know where. Turning off pipeline compilation causes matching as desired (this can be turned off in AJDT in the compiler prefs page as a workaround for now). On the command line: pr241847>ajc -showWeaveInfo *.aj *.java -1.5 Join point 'method-execution(void LongLong.m1(java.lang.String))' in Type 'LongL ong' (LongLong.java:2) advised by before advice from 'Asp' (Asp.aj:5) pr241847>ajc "-Xset:pipelineCompilation=false" -showWeaveInfo *.aj *.java -1.5 Join point 'method-execution(void CC.m1(java.lang.String))' in Type 'CC' (CC.jav a:3) advised by before advice from 'Asp' (Asp.aj:5) Join point 'method-execution(void LongLong.m1(java.lang.String))' in Type 'LongL ong' (LongLong.java:2) advised by before advice from 'Asp' (Asp.aj:5) Since II occurs alphabetically between CC and LongLong then the processing order is CC/II/LongLong in the failing case. The inconsistency is no doubt a bug in the Eclipse representation of the param annos stuff since in the non-pipeline case everything is a bcel entity.
It is what I thought it was. But fixing it is tricky due to how parameter annotations are handled inside the Eclipse compiler. The type has to be fully resolved for them to be processed correctly and accessible within the matching code. There are two possible routes to fixing this: 1 when the match is being attempted, resolve the method to ensure parameter annotations are ready. This is not ideal as the code is all currently setup for one-time resolution, there are no guards to ensure resolution has already happened (within the eclipse code). If we resolve it twice, there will be wierd errors. Resolution is also quite heavyweight since it includes resolution of any instructions within the method body, something the pipeline is designed to avoid by only working with one resolved entity at a time. 2 Change the ordering of type processing in the pipeline. We should be able to ensure that the super types (II in this case) have been through the pipeline before the subtype (CC in this case) is examined and matching is attempted. We can do this, but: - it will not be cheap. Currently to order the pipeline we do a quick check to ensure the aspects are first, and that is all. If we take this route we have to search for the superclasses/superinterfaces of all types and ensure they are first. - it could still lead to tricky situations. I can imagine a type hierarchy mixed up between source files (unusual, but could happen) that means we cannot come up with a reliable ordering that won't hit this problem.
Created attachment 108764 [details] unfinished patch... I've committed the testcode for this - but it is commented out right now (In Ajc162Tests). The patch is the starts of a fix but not finished until I decide which route to take (as described in previous comment).
I have a pointcut execution(* *(..,@NotNull (*),..) This does not match doIt(@NotNull String s) or variations thereof such as doIt(String s, @NotNull String s2). It should I would say. when I revise the pointcut to execution(* *(@NotNull (*),..) it *does* work. Commenting on this bug since this'll probably be related.
Alef, that is a known restriction. We don't currently support multiple uses of '..' in a pointcut (in any pointcut, regardless of the use of parameter annotations). I would love to have something like you propose that matches what you expect (I'd expect it too...) but I'm having a lot of trouble designing a workable syntax (considering the binding case). In fact I spent 2 hours with Rob and Adrian trying to figure it out this week, and we still havent - the enhancement that exists to cover this is bug 233718
unsetting the target field which is currently set for something already released
