[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| [aspectj-dev] ITD and anonymous inner classes, take two | 
Hi all,
we noticed another misbehavior regarding ITD returning an anonymous 
inner class (the previous one was that if the aspect is in a different 
package than the target type, the inner class is package protected and 
not accessible by the ITD method residing in the aspect, thus not 
instantiable).
We have different aspects, in different jars. Each one adds methods to a 
specific class. Some of these methods return inner classes. When the 
first jar is compiler, we obtain XX$1 and XX$2 inner classes, 
instantiated and returned by proper ITD methods. When we compile the 
second jar, we obtain AGAIN XX$1 and XX$2. When we place both the jars 
on the aspectpath, and weave-compile the final application (both at 
compile time and at load time), nobody takes care of renaming XX$1 or 
XX$2, so we end up having a method ITDeclared from one jar returning the 
XX$1 loaded from the other jar and/or the opposite, depending on the 
classpath order of the two jars.
Seems simple, took ages to debug :D
Is this a known bug/limitation ? Should I rise it?
I think this is quite similar to the bug I never managed to reproduce 
regarding closures. Since also closures are similar anonymous inner 
classes, I think the same thing happens when two jars are both declaring 
around advice, both creating closures, then both are placed on the 
aspect path, and it happens that one "overwrites" the other, creating 
far-from-easy-to-understand-and-debug problems at runtime, like a call 
to a method end up in a call to a completely different one cause the 
wrong closure is being executed.
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.
This is not a problem of working or not working weaving system, but 
simply same name of files (and consequently of classes). I think javac 
makes the same error, but in javac it is far less common to compile two 
jars containing the same class with different anonymous inner classes, 
and then place both in the same running environment, while with ITDs (or 
closures) it is by far more common.
Simone
--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/