Community
Participate
Working Groups
Build Identifier: 20100917-0705 A project containing an aspect which refers to a generic-derived class cannot be compiled with AspectJ 1.6.10 and 1.6.11, but worked with an older version (1.6.5, if I remember right.) Message: Internal compiler error java.lang.IllegalStateException: Use generic type, not parameterized type at org.aspectj.weaver.ResolvedTypeMunger.<init>(ResolvedTypeMunger.java:72) at org.aspectj.weaver.PrivilegedAccessMunger.<init>(PrivilegedAccessMunger.java:31) at org.aspectj.weaver.CrosscuttingMembers.addPrivilegedAccesses(CrosscuttingMembers.java:216) at org.aspectj.weaver.ResolvedType.collectCrosscuttingMembers(ResolvedType.java:756) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:89) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:69) at org.aspectj.weaver.bcel.BcelWeaver.prepareForWeave(BcelWeaver.java:502) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.ensureWeaverInitialized(AjPipeliningCompilerAdapter.java:529) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.weaveQueuedEntries(AjPipeliningCompilerAdapter.java:509) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.queueForWeaving(AjPipeliningCompilerAdapter.java:447) at org.aspectj.ajdt.internal.compiler.AjPipeliningCompilerAdapter.afterProcessing(AjPipeliningCompilerAdapter.java:432) at org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:652) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1021) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:305) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:185) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.performBuild(AjdeCoreBuildManager.java:127) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:91) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:257) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Always Steps to Reproduce: 1. Create a new AspectJ project in Eclipse IDE. 2. Add a file MyList.java to the source folder: import java.util.ArrayList; class MyList extends ArrayList<Integer> {} 3. Add a file MyList_Serializable.aj to the source folder: import java.io.Serializable; aspect MyList_Serializable { declare parents : MyList implements Serializable; private static final long MyList.serialVersionUID = 1L; // causes compiler failure } 4. Enjoy compiler message.
thanks for the testcode, that really helps! There are two issues lurking here. The first is that we should use the raw type and not the parameterized form. The second is that sometimes we make a mistake when resolving a field, in this case serialVersionUID. When creating accessors for private ITDs we have the signature of the new member and attempt to resolve it. For a normal field this is fine, but for an ITD field we can accidentally resolve to the 'wrong thing' if the supertype also declares that field (like ArrayList also declares serialVersionUID in this case). Both are fixed and test is committed.
