Community
Participate
Working Groups
Hi all, I've encountered a slightly odd thing with generic abstract aspects packaged in Jar files and I'm not sure whether it's a bug or just incorrect syntax on my part. The code in question is: File AbstractAspect.aj: > public abstract aspect AbstractAspect<T> { > interface target<C> { > public C get(); > } > > declare parents: T implements target; > > private int target<C>.aField; > public C target<C>.get() { return null; } } File TestAspect.aj: > aspect TestAspect extends AbstractAspect<Student> {} (details of the Student class are not important here) There are two scenarios: 1) Compile AbstractAspect.aj, TestAspect.aj and Student.java statically using ajc. This works fine. 2) Compile AbstractAspect.aj separately and put into Jar file. Then compile TestAspect.aj and Student.java using ajc, with the Jar file on the classpath. This does not work. The error message reported is: > Inconsistent classfile encountered: The undefined type parameter C is > referenced from within AbstractAspect<T> public aspect TestAspect > extends AbstractAspect<Student> { } ... I have observed that removing <C> from "target<C>.aField" and "Target<C> get()" makes it work. I also tried using <D> instead of <C> in "target<C>.aField" and "Target<C> get()", but this didn't make any difference. Curiously, though the error message still referred to the "C" (which was still present in the interface definition). Anyway, I have attached the complete example as a tarball. Cheers, David Pearce
Created attachment 33535 [details] Example code
first comment - dont use -noweave - it wont fix your problem but you shouldnt use it. Reweavable is now the default and makes -noweave useless.
ok, bit more investigation. this bug is a real pain. The problem is that the signature attached to the ITD refers to a type variable that exists on a member type, not on the enclosing type for the ITD. When used as input to a subsequent weaving stage, the compiler creates a BinaryTypeBinding for the class and barfs when it can't sort out the signature and resolve the type variable. With some magic, I can fix it in the case like this where the ITDs are on a member type within the same enclosing type. What I think will cause me problems is ITDs like this that are made on an entirely separate type. I seem to have two options: 1. attempt to resolve the type variable there and then by discovering the actual target (tricky - without processing the ITD, how do I know the target) 2. suppress the error for the ITD case like this and 'sort it out later' when the ITDs are processed. option (2) seems nice.
really want to get to this, but 1.6.1 is already full of changes.
Similar workaround as done in bug 242797 would make this work - that was for generic ITDs, this is generic aspects.
not doing any more on this in the short term, very few people hitting it
