Bug 80208 - [1.5][compiler] NPE trying to resolve single static import
Summary: [1.5][compiler] NPE trying to resolve single static import
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M4   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-04 10:12 EST by Olivier Thomann CLA
Modified: 2004-12-14 11:30 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2004-12-04 10:12:39 EST
Using latest, I got a NPE trying to compile the three classes below:
-----------------------------------------------------
package p1;

public class C {
    public static int F() {
        return 0;
    }
}
-----------------------------------------------------
import static p1.C.F;
import p2.*;

public class X implements F {
}
-----------------------------------------------------
package p2;

public interface F {}
-----------------------------------------------------
java.lang.NullPointerException
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findField(Scope.java:703)
	at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleStaticImport(CompilationUnitScope.java:440)
	at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:423)
	at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:586)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2258)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2042)
	at
org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:39)
	at
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:141)
	at
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveSuperType(TypeReference.java:104)
	at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1067)
	at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperInterfaces(ClassScope.java:805)
	at
org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:863)
	at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:243)
	at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:195)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:307)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:321)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:1685)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:375)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:268)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:260)
	at org.eclipse.jdt.core.tools.compiler.Compile.main(Compile.java:19)

The problem seems to come from the class C for which the super interfaces are
null instead of NoSuperInterfaces.
Comment 1 Kent Johnson CLA 2004-12-07 14:29:15 EST
Fixed the walkback.

Still need to support static imports of method names, but that is covered in 
another PR.
Comment 2 Olivier Thomann CLA 2004-12-14 11:30:07 EST
Verified in 200412140800
Comment 3 Olivier Thomann CLA 2004-12-14 11:30:17 EST
Verified in 200412140800