Community
Participate
Working Groups
I'm getting an Internal Compiler Error. It does not happen with a particular class (If I remove the class the error jumps to the next class in the list). The error is: Severity Description Resource In Folder Location Creation Time 2 Internal compiler error java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getMemberType(BinaryTypeBinding.java:606) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:898) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:936) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:754) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:887) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:232) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:486) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:465) at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:190) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:99) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:43) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:51) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:167) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:403) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:456) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:640) at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2372) at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2137) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.internalResolveType(ParameterizedSingleTypeReference.java:99) at org.eclipse.jdt.internal.compiler.ast.ParameterizedSingleTypeReference.resolveType(ParameterizedSingleTypeReference.java:217) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1088) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:755) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:927) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:254) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:240) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:190) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:50) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:213) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:141) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:593) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:168) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:202) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:231) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:234) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:253) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:282) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:139) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:200) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) AuctionCategory.java www.rcpauction.com/WEB-INF/src/com/rcpauction/business line 0 September 28, 2005 4:33:58 PM -------------------- The class itself (if it matters) is very simple: package com.rcpauction.business; public class AuctionCategory extends com.rcpauction.business.generated.AuctionCategory { public AuctionCategory() { } public AuctionCategory(String name) { super(name); } }
Could you please provide a complete test case? What is your build id? Could you please see if you can reproduce with the upcoming 3.1.1 build?
What do you mean by a full test case? I'm disinclined to give you my full project or workspace. For what is worth I'm using tons of 1.5 features, generics and what not. I'll try 3.1.1 and see if it makes a difference. Not to dis you or anything, but it shouldn't be that hard to figure it out, it's a NullPointerException and I'm giving you the line number. From the line you should be able to figure out if either the null is normal, in which case you handle it, or it is a wrong value and you figure out how it got there (though you probably should still handle it). Thanks.
It still happens with a newly installed 3.1.1 stream build.
Please provide steps to reproduce. Your testcase does show anything. To answer comment 2, no null value at this point is fine, and handling it locally is not how we solve issues. We first need to understand how this can occur, and therefore we need a better testcase. It seems to have to do with binary member types (from classfiles), and to be in a scenario where some errors have been detected already. Suspicion is that your classpath would be incomplete, but the compiler crashes at some point, which is unhappy. Could you reduce the error to a manageable set, which you can remove all sensible source code from ?
Previous post should read: Please provide steps to reproduce. Your testcase does *NOT* show anything.
Created attachment 27690 [details] Test case I'm attaching the project with the problem, I've removed everything until only the problem remains
Created attachment 27691 [details] This is the other file involved in the test case You might want to have this to be able to see what the problem might be.
OK, I think I got it figured out... All this code was working before, but I began to "generalize" my libraries and this particular class XDAO, was declared in a way that it's declaration required an instantiation of the same template to generate an inner class definition. In essence, some sort of recursion was taking place. I took the inner class out and thus simplified the whole thing and the internal compiler error went away. Now, you might still want to fix this to provide more meaningful messages, but at least I can go on working and won't have to start using netbeans :)
We want to address this, don't worry. Thanks for the testcase.
Can you please reattach the project - it appears the file was corrupted.
OK, knowing what I know, I've reproduced it with a much simpler test case. Boy what I do for open source, I should be awarded a medal :) public class A<T1> { } public class B<T2> extends A<B<T2>.Inner> { public class Inner { } } public class C { public C() { B<Integer> b = new B<Integer>(); } }
Incidentally, I get no complaints at all from javac when I compile these three files.
Reproduced. Thanks for the testcase.
Added GenericType test833(). Released fix to BinaryTypeBinding into HEAD.
Kent - pls release it as well to 3.1 maintenance stream (in case of future rollup)
done.
Verified for 3.1.2 using build M20060109-1200.
Verified for 3.2 M4 using build I20051215-1506.
