Community
Participate
Working Groups
I get the exception below when I enable AspectJ on my Java project: java.lang.IllegalStateException at org.aspectj.weaver.TypeFactory.createParameterizedType(TypeFactory.java:42) at org.aspectj.weaver.bcel.BcelGenericSignatureToTypeXConverter.classTypeSignature2TypeX(BcelGenericSignatureToTypeXConverter.java:82) at org.aspectj.weaver.bcel.BcelGenericSignatureToTypeXConverter.classTypeSignature2TypeX(BcelGenericSignatureToTypeXConverter.java:42) at org.aspectj.weaver.asm.AsmDelegate.ensureSignatureUnpacked(AsmDelegate.java:410) at org.aspectj.weaver.asm.AsmDelegate.getDeclaredInterfaces(AsmDelegate.java:538) at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:426) at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:64) at org.aspectj.weaver.ResolvedType.collectInterTypeMungers(ResolvedType.java:1155) at org.aspectj.weaver.ResolvedType.getInterTypeMungersIncludingSupers(ResolvedType.java:1134) at org.aspectj.weaver.ResolvedType.checkInterTypeMungers(ResolvedType.java:1201) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDeclarations(AjLookupEnvironment.java:643) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.weaveInterTypeDeclarations(AjLookupEnvironment.java:519) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.createBinaryTypeFrom(AjLookupEnvironment.java:1058) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:480) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:190) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:111) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:43) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:53) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:167) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:413) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:466) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:331) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:400) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:512) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:329) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:887) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:244) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:163) at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:122) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191) IllegalStateException thrown: Expecting raw type
Once this problem has occurred, all *.aj files are opened with the Java editor instead of the AspectJ editor.
we've fixed a few cases of this ... guess this is another one....
I've reproduced this failure - not sure if its via the route the raiser is using but I'm going to fix the case I've found. I have a Java5 type with a member: Pair<String,String> foo; Where Pair is: class Pair<A,B> {} All fine.... the problem I see is because after initial compilation, in an LTW environment, we reuse the type containing the member 'foo' in an situation where Pair is not-generic (ie. probably a back level of the library containing Pair). The code that unpacks the signature for the member is expecting Pair to be in its 'raw' form (ie. it is actually a generic type underneath) - when we discover it isnt, we go bang. In these situations where we cannot parameterize the non-generic type, we'll continue with the simple type that has been found. I can't immediately think of a situation where this will get us into trouble. I am adding trace entries for this situation so that it is logged in future and we can more easily diagnose what is going wrong.
i think this has now been resolved - we allow the type that was discovered to be non-generic and continue with the simple type. please reopen if it still happens for you.
