Community
Participate
Working Groups
In what is perhaps related to bug 169600, I am getting the following compilation error: java.lang.ArrayIndexOutOfBoundsException at org.aspectj.weaver.ResolvedType.getMemberParameterizationMap(ResolvedType.java:695) at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:406) at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:65) at org.aspectj.weaver.ResolvedType.collectInterTypeMungers(ResolvedType.java:1156) at org.aspectj.weaver.ResolvedType.collectInterTypeMungers(ResolvedType.jav ... .java:102) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191) ArrayIndexOutOfBoundsException thrown: 0
I am getting the same error. But not the one from bug 169000 (yet).
Meanwhile I am getting the exception from bug 169600 as well. But the ArrayIndexOutOfBoundsException comes first. I am using WinXP, AspectJ 1.5.3 and AJDT 1.4.1. This seems to be a AJDT Bug, not AspectJ, don't you think so?
the stack trace doesnt involve any AJDT code - so I think it is an aspectj problem.
this bug is because of something about your use of generic types. Are you able to describe the hierarchy to any degree? How are the type variables inherited through your declarations? Do you parameterize partial generic signatures in your subtypes?
Everyone, This is a full stack trace when running from Eclipse with AJDT in case it is any help: java.lang.ArrayIndexOutOfBoundsException: 0 at org.aspectj.weaver.ResolvedType.getMemberParameterizationMap(ResolvedType.java:695) at org.aspectj.weaver.ReferenceType.getDeclaredInterfaces(ReferenceType.java:406) at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:65) at org.aspectj.weaver.ResolvedType.collectInterTypeMungers(ResolvedType.java:1157) at org.aspectj.weaver.ResolvedType.collectInterTypeMungers(ResolvedType.java:1159) at org.aspectj.weaver.ResolvedType.getInterTypeMungersIncludingSupers(ResolvedType.java:1136) at org.aspectj.weaver.ResolvedType.checkInterTypeMungers(ResolvedType.java:1203) 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:1060) 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.BinaryTypeBinding.getMemberType(BinaryTypeBinding.java:618) at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:444) 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:973) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:290) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.incrementalBuild(AjBuildManager.java:184) at org.aspectj.ajde.core.internal.AjdeCoreBuildManager.doBuild(AjdeCoreBuildManager.java:88) at org.aspectj.ajde.core.AjCompiler.build(AjCompiler.java:96) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:219) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:621) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:163) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:194) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:243) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) For me, this problem mostly occurs when I have incremental build on in Eclipse and make a change that is either: 1) Non code modifying change. I.E. Changing whitespace, comments, etc. 2) Save a file (and thus auto build triggers) which has errors in it. As far as what the type hierarchy is like, it is a fairly large project, so I'm not sure where to start. Anything specific you are looking for? The class that was auto-built and generated the above exception is not generic, but it does have/use member variables that are generic. Would this potentially affect it as well?
Interesting find. So my previous bug report was running under JRockit JDK 5 Update 8 R27.1.0. I just tried changing back to JVM 1.6 and everything works fine. Auto compilation, everything. Kind of strange considering AspectWerks and AspectJ merged not to long ago. Not sure if it is an AspectJ or a JRockit thing, but it would nice to see this get fixed soon.
> The class that was auto-built and generated the above exception > is not generic, but it does have/use member variables that are > generic. Would this potentially affect it as well? Yes. It is also interesting that it happens on incremental builds. Behaving differently at different VM levels can entirely be down to how they have implemented internal classes using generics.
> Yes. It is also interesting that it happens on incremental builds. I wouldn't say that it is not limited to auto builds, only. However, that is the most common/reproducible occurence. But it does also happen during a standard compile, all-be-it less frequently. > Behaving > differently at different VM levels can entirely be down to how they have > implemented internal classes using generics. So assume this is something that JRockit would need to fix? Or is this potentially something wrong with the implementation of generics in AspectJ's compiler?
> So assume this is something that JRockit would need to fix? Or is this > potentially something wrong with the implementation of generics in AspectJ's > compiler? No fix in JRockit required - it is purely an AspectJ bug. There is something in the way generics are being used in the classes upon which you depend which is perfectly valid but AspectJ hasn't seen it before and can't cope with it.
Created attachment 63693 [details] LTW on JRocket can cause the same exception Installing Glassbox into WebLogic 10 running on JRocket generated the same exceptions with only weblogic and org.aspectj.weaver code in the stacktrace. Hope this ajcore file helps!
I am getting the same bug in Eclipse when changing a specific class file that has many references to generic types. It will happen either when I have Build Automatically set or when I compile explicitly. The only thing that fixes the problem is to clean my project and start a fresh compile. So far that has solved the problem every time. I am introducing AspectJ to our development team, and they are excited to use the technology but a little hesitant. Even though this bug is not fatal (we have a work-around), it's annoyance may cause our team to loose confidence in using AspectJ - so I am curious why the severity level on this is "normal"?
Changing OS from Mac OS to Mac OS X as per bug 185991
I am closing this as a dup of bug 175039. That bug covers the same stack trace but also includes an explanation of the problem and a fix was put in under that bug on the 6Mar2007. Of all these similar bugs I have yet to see one reported on an AspectJ level after the 6Mar2007 Comment 2 here mentions 1.5.3 (22Nov2006) Comment 10 includes a core file for a build of 28Feb2007 *** This bug has been marked as a duplicate of bug 175039 ***
