Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 2 Build id: 20120216-1857 AJDT version info: Version: 2.2.0.e37x-RELEASE-20120704-0900 AspectJ version: 1.7.0.20120703164200 Error log contains: Internal compiler error: java.lang.ClassCastException: org.aspectj.weaver.MissingResolvedTypeWithKnownSignature cannot be cast to org.aspectj.weaver.ReferenceType at org.aspectj.weaver.BoundedReferenceType.parameterize(BoundedReferenceType.java:109) Dialog has a bit more info: java.lang.ClassCastException at org.aspectj.weaver.BoundedReferenceType.parameterize(BoundedReferenceType.java:109) at org.aspectj.weaver.ResolvedType.parameterize(ResolvedType.java:2434) at org.aspectj.weaver.ResolvedMemberImpl.parameterize(ResolvedMemberImpl.java:872) at org.aspectj.weaver.ResolvedMemberImpl.parameterizedWith(ResolvedMemberImpl.java:764) at org.aspectj.weaver.ResolvedMemberImpl.parameterizedWith(ResolvedMemberImpl.java:717 ... Compile error: ClassCastException thrown: org.aspectj.weaver.MissingResolvedTypeWithKnownSignature cannot be cast to org.aspectj.weaver.ReferenceType Reproducible: Always Steps to Reproduce: The project in which error happens is quite complex and I don't know what causes the exception.
I've cloned git repo and stepped through code. This is stack trace: <pre> Thread [Worker-12] (Suspended (exception ClassCastException)) BoundedReferenceType.parameterize(Map<String,UnresolvedType>) line: 109 ReferenceType(ResolvedType).parameterize(Map<String,UnresolvedType>) line: 2434 BcelField(ResolvedMemberImpl).parameterize(UnresolvedType, Map<String,UnresolvedType>, boolean, World) line: 872 BcelField(ResolvedMemberImpl).parameterizedWith(UnresolvedType[], ResolvedType, boolean, List<String>) line: 764 BcelField(ResolvedMemberImpl).parameterizedWith(UnresolvedType[], ResolvedType, boolean) line: 717 ReferenceType.getDeclaredFields() line: 621 ResolvedType$FieldGetter.get(ResolvedType) line: 284 ResolvedType$FieldGetter.get(Object) line: 282 Iterators$4$1.hasNext() line: 213 Iterators$6.hasNext() line: 288 Iterators$4.hasNext() line: 230 HasMemberTypePattern.hasField(ResolvedType) line: 64 HasMemberTypePattern.matchesExactly(ResolvedType) line: 49 HasMemberTypePattern(TypePattern).matchesStatically(ResolvedType) line: 132 DeclareParents.match(ResolvedType) line: 63 DeclareParents.findMatchingNewParents(ResolvedType, boolean) line: 358 AjLookupEnvironment.doDeclareParents(DeclareParents, SourceTypeBinding) line: 886 AjLookupEnvironment.weaveInterTypeDeclarations(SourceTypeBinding, List<ConcreteTypeMunger>, List<DeclareParents>, List<DeclareAnnotation>, boolean, int) line: 736 AjLookupEnvironment.weaveIntertypes(List<SourceTypeBinding>, SourceTypeBinding, List<ConcreteTypeMunger>, List<DeclareParents>, List<DeclareAnnotation>, int) line: 424 AjLookupEnvironment.completeTypeBindings() line: 261 Compiler.internalBeginToCompile(ICompilationUnit[], int) line: 755 Compiler.beginToCompile(ICompilationUnit[]) line: 381 Compiler.compile(ICompilationUnit[]) line: 426 AjBuildManager.performCompilation(Collection<File>) line: 1028 AjBuildManager.performBuild(AjBuildConfig, IMessageHandler, boolean) line: 272 AjBuildManager.batchBuild(AjBuildConfig, IMessageHandler) line: 185 AjdeCoreBuildManager.performBuild(boolean) line: 105 AjCompiler.buildFresh() line: 100 AJBuilder.build(int, Map, IProgressMonitor) line: 255 BuildManager$2.run() line: 728 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 199 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 239 BuildManager$1.run() line: 292 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 295 BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 351 BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 374 Workspace.buildInternal(IBuildConfiguration[], int, boolean, IProgressMonitor) line: 513 Workspace.build(IBuildConfiguration[], int, boolean, IProgressMonitor) line: 432 BuildAction$1.runInWorkspace(IProgressMonitor) line: 305 BuildAction$1(InternalWorkspaceJob).run(IProgressMonitor) line: 38 Worker.run() line: 54 </pre> The offending ReferenceType is actually com.mysema.query.types.ExpressionBase<ApplicationInfo> meaning it's trying to do something with QueryDSL generated classes. The scenario is something like this: - we use "security" aspect which declares common parent on secured objects, and inserts required methods and fields - same objects could be JPA entities, which are processed by the QueryDSL (apt processor which is invoked separately from CLI - we've learned that apt doesn't work well with AJDT) If I manually remove source folder with generated QueryDSL classes AJDT compilation suceeeds. I suspect that QueryDSL generated class triggers this error.
Please ignore. The issue was: - querydsl generated classes were not removed properly on Project -> Clean - aspectj (AJDT) found old classes and we got exception I have manually deleted querydsl generated classes, regenerated querydsl classes, and AJDT compilation suceeds. OTOH, it would really help us if there were clear integration between AJDT, apt processors and maven. I see more and more maven projects that querydsl in combination with AJDT and while on paper it seems like a match made in heaven, in practice it requires too much error prone configuration magic.
I'm reopening this bug to see if there is something we can do here. It might be that querydsl is generating byte-code that AspectJ cannot handle. There are two possibilities, either this is an annotation processor problem, or it is a byte code problem. Were you seeing this error only inside of Eclipse or also when running mvn on the command line? Inside of Eclipse AspectJ is used to compile all source code and Java6 style annotation processors are not supported. From maven, java code is compiled by javac and aspect code by ajc. And the java classes are subsequently woven by aspectj. This means that we can get away with annotation processors that do not affect aspects and new kinds of byte code that is not affected by the weaver. So, if there is anything we can do, it would be on the aspectj side of things.
Converting this to an AspectJ project. Ivica, if you can describe a way to reproduce, then we may be able to look at it.
Hi Andrew. I generated QueryDSL classes from command line. In the meantime somebody refactored original code and moved some of the JPA entities into a different package. I have updated the code and just regenerated QueryDSL Q classes (notice that I didn't run maven clean or removed previously generated classes). Old version of classes were left untouched in the folder with manually generated sources. Now I had old classes and new classes. When AJDT compiler kicked in I got CCE. I guess that aspectj view of the world was in inconsistent state and it couldn't tell me that I had old code in the source folders.
When I say "generate classes" I really mean "generate source code".
