Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] ITD and anonymous inner classes, take two

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
>


Back to the top