[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] ITD and anonymous inner classes, take two
|
Hi Andy,
I suspected that, and in fact tried if the same was happening on class
compiled with plain javac, and it happens, but surely it's not a common
use case for javac (well, it's a deploy error), while it could be a use
case for ajc.
I raised bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262102 to
track this.
Simone
Andy Clement wrote:
I don't believe AspectJ gets involved in the naming of those anonymous
inner classes, we just leave it to the compiler - but from your
description of the scenario, it probably should when they are used in
ITDs. I would raise this as a bug.
cheers,
Andy.
2009/1/22 Simone Gianni <simoneg@xxxxxxxxxx>:
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/
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
