Community
Participate
Working Groups
Created attachment 193418 [details] JUnit Eclipse project Error below occurs upon compiling intermittently, regularly, but not always. java.lang.ClassCastException at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.BlockScope.getEmulationPath(BlockScope.java:732) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.SingleNameReference.generateCode(SingleNameReference.java:395) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.MessageSend.generateCode(MessageSend.java:152) at org.aspectj.org.eclipse.jdt.internal.compiler.ast.Expression.generateCode(Expression.java:60 ... tj.org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding cannot be cast to org.aspectj.org.eclipse.jdt.internal.compiler.lookup.NestedTypeBinding I have taken the JUnit source code and am working with examples from Kiczales to implement design patterns using AspectJ. The problem started occuring when I added the aspects junit.kiczales.patternlibrary.TestComposite and junit.kiczales.patternlibrary.CompositeProtocol
Thanks for the instructions to recreate. The problem here is that on some kinds of build (an incremental build typically), not everything is represented as source. When you have ITDs onto inner types that themselves define anonymous local classes then some of the eclipse infrastructure is driven in an unfamiliar way. For example it assumes that if you are dealing with the source form of an anonymous local class then all the surrounding types are also in source form (they would be in java). But if you are using an ITD then the local class may be in source form but the target of the ITD and its parent will be 'binary' (being loaded in their binary form from the previous full build). This breaks an eclipse assumption and this CCE comes out. I've put in a guard for now. This fix will make it into AJDT the next time I update AJDT with an AspectJ, I've already done it today, I'll probably do another one later this week.
