[
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/