Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: 1. Explanation: Compilation fails with AJDT build 1.5.3.200806091332 when calling a method on a data member when this data member itself contains a data member which is an array of a doubly generic type. The exact compiler error is: === org.aspectj.weaver.BCException at org.aspectj.weaver.UnresolvedType.signatureToName(UnresolvedType.java:628) at org.aspectj.weaver.UnresolvedType.signatureToName(UnresolvedType.java:603) at org.aspectj.weaver.UnresolvedType.getName(UnresolvedType.java:403) at org.aspectj.weaver.bcel.ClassPathManager.find(ClassPathManager.java:97) at org.aspectj.weaver.bcel.BcelWorld.lookupJavaClass(BcelWorld.java:318) at org.aspectj.weaver.bcel.BcelWorld.res ... 18) method-execution(void genericArrayError.SomeClass.someMethod()) end public void someMethod() end public class genericArrayError.SomeClass === Ashtonishingly, this compiler error disappears when including a data member of the doubly generic type in the member class. This code compiles without problems as standard java code in Eclipse, but not when it is compiled with AJDT enabled... The sample code is probably much clearer than this explanation. 2. Sample Code: ==GenericClass== public class GenericClass<Type extends Object> { } == ==GenericGenericMemberClass== public class GenericGenericMemberClass { // this line never causes a problem GenericClass<Double> [] genericMemberArray; // this line causes compilation errors to be introduced GenericClass< GenericClass<Double> >[] genericGenericMemberArray; // uncommenting the following lines removes the compilation errors (very unexpectedly, for me at least) // @SuppressWarnings("unused") // private static final GenericClass< GenericClass<Double> > genericGenericMember = null; public void test() { } } == ==SomeClass== public class SomeClass { GenericGenericMemberClass member; public void someMethod() { // commenting the following line will remove compilation errors (and mask the problem) member.test(); } } == More information:
I'm not denying there is a bug here, but I just can't get this to fail. I am on a very recent AJDT (more recent than you 1.5.3.200806161812) but haven't knowingly fixed anything in this area. I have all 3 files in an AJDT project, happily building - i've tried cleaning, modifying them individually, etc - and nothing makes the error appear. I also tried building them on the command line and still it all works. I also tried with AspectJ 1.5.4 and 1.6.0 and they both compile it too. Is there anything else you are doing that I'm not? Are you doing full clean builds or incremental builds?
There is something that I was doing that you're not, but I didn't think it would be related. I compiled the files in a testproject where there was some unrelated aspect code. If you add such an unrelated aspect, the error will show up. In the aspect, there has to be some advice, but the kind of advice doesn't seem to matter (i've briefly tested with before and around advice with various different 'call' pointcuts). The advice itself doesn't need to match any of the 3 files i've described before, or to anything else for that mather. ==UnrelatedAspect== public aspect UnrelatedAspect { // commenting the following advice will remove compilation errors (and mask the problem) before() : call(void UnrelatedClass.unrelatedMethod()) { } } == kind regards, Wim (In reply to comment #1) > I'm not denying there is a bug here, but I just can't get this to fail. > > I am on a very recent AJDT (more recent than you 1.5.3.200806161812) but > haven't knowingly fixed anything in this area. > > I have all 3 files in an AJDT project, happily building - i've tried cleaning, > modifying them individually, etc - and nothing makes the error appear. I also > tried building them on the command line and still it all works. I also tried > with AspectJ 1.5.4 and 1.6.0 and they both compile it too. > > Is there anything else you are doing that I'm not? > > Are you doing full clean builds or incremental builds? >
thanks for the extra info. I found I also had to compile them in a certain order to see this problem on the command line - good old pipelining compilation :) ajc GenericClass.java SomeClass.java GenericGenericMemberClass.java UnrelatedAspect.java -1.5 The parameterized signature processing code was a bit naive, I've now upgraded it to cope with any level of nesting. fix committed.
