Community
Participate
Working Groups
Steps To Reproduce: 1. Create a class and package it in a jar. 2. Create an aspect, adding an ITD method on the previous class, and return an anonymous inner class from that method. Package this aspect in a jar. 3. Do the same thing again in another jar, with another method name. 4. Put all the three jars together, the first on the classpath and the other two on the aspectpath of an LTW system. 5. Call the first ITD method, then the second, they will both return the same anonymous inner class. More information: Simple, both anonymous inner classes are named TargetClass$1, so they overlap when both aspects are placed on the classpath. The compiler behavior is correct (in that, in both contexts, there is just one anonymous inner class), and javac does the same, but since this is a possible use case for AspectJ, it should be handled somehow. Possible solutions that pops in my mind : - Don't name anonymous inner classes $1 $2 etc.. but use a more random numbering scheme (hash of the aspect name, append the ITD method name, whatever). I don't know if $1 $2 etc.. is required by the JVM (cannot find it in the specs), looking the bytecode it seems like they are more or less like other classes. - Don't name anonymous inner classes using the ITD target class name, but the aspect name instead. Again, I don't know if the name of an inner class is bound to the containing class name by specs, but cannot find any reference to such a limitation.
Occasionally, but it's not easy to reproduce it, this happens also for closures. If I have aspectA and aspectB both advicing a certain class, but compiled in different packages (different ajc runs), they could generate colsure names that collide when the three jars (the one with aspectA, the one with aspectB and the one with the original class) are placed on the classpath of a running application. This happened to me only three times in two years of development with AspectJ, but the first time I spent a week trying to figure out what was going on. Calling a method caused execution of another method and all kind of JVM errors to occurr, and it was simply because the method was calling a closure that was then forwarding to another method.
