Community
Participate
Working Groups
I have some AspectJ code that uses cflow tests. However, when it is rewoven this doesn't preserve the generated names of the cflow fields so when accessing some methods with the cflow test I get this kind of error at runtime: java.lang.NoSuchFieldError: ajc$cflowStack$2
this goes back to a discussion we were having about name stability a while ago. We did a good job with advice names but this is a known problem. The problem with fixing it is affecting code that has already been built with older versions of AJ where you don't necessarily want to recompile - I need to do a bit of magic to make us compatible with 'older code'. If I give you a drop of AspectJ with a potential fix in Ron, can you try it in your scenario or are you too tied up in working with head or your private build?
Agreed. Sounds promising... I could definitely test it: on this project we're using standard production builds of AspectJ as much as possible.
ok, thanks Ron. Here is a dev build containing robust names: http://www.eclipse.org/downloads/download.php?file=/technology/aspectj/dev/aspectj-ron1.jar let me know if it works for you...
I can't believe it. I tried on 2 projects where I've seen this problem before but perhaps unsurprisingly a few small changes have perturbed the situation and now I can't reproduce it even with the normal AspectJ builds ... I will keep looking to see if I can recreate this to test the fix...
Ok, I found a reproducible test case where reweaving cflow fields changes names and cflow is incorrectly not matching when reweaving. I tried the Apr. 20 special build attached and it is still failing but now giving more information. Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$2c2213b7 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1cf3f0ae Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$ee241bf4 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1b2ecfb0 Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$fee9398 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$9ccb6815 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$84a2da07 Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$t$5347c517 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$2c2213b7 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1cf3f0ae Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$ee241bf4 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1b2ecfb0 Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$fee9398 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$9ccb6815 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$84a2da07 Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$t$5347c517 [application output:] enter tech tip 1 [entering pointcut A] enabled... cflow? [entering pointcut B] This then fails with this exception when it hits cflow(A) && B: java.lang.NoSuchFieldError: ajc$cflowStack$f$1cf3f0ae … Note that this project is using load-time weaving and fails in this way when I exclude reweaving of the aspects themselves. If I weave everything then it fails in a different way: Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$2c2213b7 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1cf3f0ae Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$ee241bf4 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1b2ecfb0 Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$fee9398 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$9ccb6815 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$84a2da07 Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$t$5347c517 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$2c2213b7 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$d67065ea Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$f$c22068e5 Stack: oldname: ajc$cflowStack$2 newname:ajc$cflowStack$f$7e175210 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1cf3f0ae Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$ee241bf4 Stack: oldname: ajc$cflowStack$0 newname:ajc$cflowStack$f$1b2ecfb0 Stack: oldname: ajc$cflowStack$1 newname:ajc$cflowStack$f$fee9398 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$9ccb6815 Counter: oldname: ajc$cflowCounter$0 newname:ajc$cflowCounter$f$84a2da07 Counter: oldname: ajc$cflowCounter$1 newname:ajc$cflowCounter$t$5347c517 java.lang.NoSuchFieldError: ajc$cflowStack$f$7e175210
interesting... so do you have a small testcase now or is it too complicated? given that the new names are stable, it is either that they cannot be put into the class file they need to be put in, or the type the weaver thinks the field is in is not correct and so the field reference in the woven class is wrong... possibly due to some of the optimizations for counter/stack sharing.
At this stage I have a repeatable JUnit test I can run inside Eclipse that depends on a number of other classes. I could try to winnow it down to isolate the problem... I could also try running a build that gathers more data about what's happening. Note that I am just using aspectjweaver.jar from this build, AJDT is building the classes from .aj files (hence the old cflow names).
Ron - could you turn on dumping for LTW and give me the core woven classes that are involved in the test case? I just want to take a look inside them, I'll need the aspect in question and the places where the cflow is applying. An idea of the ordering in which the types are getting woven (verbose output..) would be helpful. Are multiple aspects involved in this configuration, or just one? Rather than using the stable name fix and a different level of AJDT to build the .aj files - can you try all this on just a recent version of AJ where the weaver at compile time and LTW time matches?
This is not (strictly speaking) an LTWeaving bug as it could be produced using ordinary binary weaving. I think the ball is in Ron's court.
still a problem?
