Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NullPointerException: Cannot invoke "TypeBinding.kind()" because "type" is null #986

Closed
liefke opened this issue Apr 19, 2023 · 5 comments
Closed
Labels
needinfo Further information is requested

Comments

@liefke
Copy link

liefke commented Apr 19, 2023

I just migrated from Eclipse 2022-12 to 2023-03.

Now I get the following exception when building or editing some of the classes in my project:

java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.internal.compiler.lookup.TypeBinding.kind()" because "type" is null
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.convertToRawType(LookupEnvironment.java:844)
	at org.eclipse.jdt.internal.compiler.lookup.RawTypeBinding.initializeArguments(RawTypeBinding.java:238)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.substitute(ParameterizedTypeBinding.java:1432)
	at org.eclipse.jdt.internal.compiler.lookup.Scope$Substitutor.substitute(Scope.java:586)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.substitute(Scope.java:530)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedFieldBinding.<init>(ParameterizedFieldBinding.java:36)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.fields(ParameterizedTypeBinding.java:609)
	at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.getField(ParameterizedTypeBinding.java:803)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findField(Scope.java:1437)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.findField(Scope.java:1383)
	at org.eclipse.jdt.internal.compiler.lookup.MethodScope.findField(MethodScope.java:473)
	at org.eclipse.jdt.internal.compiler.lookup.BlockScope.getBinding(BlockScope.java:623)
	at org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.resolveType(QualifiedNameReference.java:1029)
	at org.eclipse.jdt.internal.compiler.ast.MemberValuePair.resolveTypeExpecting(MemberValuePair.java:93)
	at org.eclipse.jdt.internal.compiler.ast.Annotation.resolveType(Annotation.java:932)
	at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(ASTNode.java:958)
	at org.eclipse.jdt.internal.compiler.ast.ASTNode.resolveAnnotations(ASTNode.java:788)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.initAnnotationTagBits(SourceTypeBinding.java:1657)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getAnnotationTagBits(SourceTypeBinding.java:1642)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.getNullDefault(SourceTypeBinding.java:2054)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.hasDefaultNullnessFor(ClassScope.java:1737)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.findSupertype(ClassScope.java:1671)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:1176)
	at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1454)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:394)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:521)
	at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:881)
	at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:394)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1248)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:790)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1245)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:868)
	at org.eclipse.jdt.core.manipulation.CoreASTProvider$1.run(CoreASTProvider.java:294)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.jdt.core.manipulation.CoreASTProvider.createAST(CoreASTProvider.java:286)
	at org.eclipse.jdt.core.manipulation.CoreASTProvider.getAST(CoreASTProvider.java:199)
	at org.eclipse.jdt.core.manipulation.SharedASTProviderCore.getAST(SharedASTProviderCore.java:138)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:166)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$1.run(SelectionListenerWithASTManager.java:151)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

I could narrow the problem down to this class:

package mypackage;

@Deprecated(since = Example.SINCE)
class Example<T> implements Serializable {
	
	static final String SINCE = "...";

	private T target;

}

The real class looks different and is much more complex, Serializable and Deprecated are just examples. The problem occurs with any other annotation or interface and even when dropping the implements Serializable and using a super class instead. If I import Example into another class (even without using it), I get the same error for that class, too.

If I remove either the implements, the annotation or the target attribute, or if I inline the since reference, the error is gone. As a workaround I'm using the inline String in the annotation (@Deprecated(since = "...")).

@iloveeclipse
Copy link
Member

I can't reproduce in a new Java project, please attach project with all settings etc.
Note that your example has compile error:
image

@iloveeclipse iloveeclipse added the needinfo Further information is requested label Apr 19, 2023
@liefke
Copy link
Author

liefke commented Apr 19, 2023

It is after all just an example - the NPE occurs no matter if I add the import for Serializable or not.

But as you say, you can't reproduce it with a new Java project, I narrowed the problem further down: I have annotation-based null analysis turned on (as you can see from my stacktrace - SourceTypeBinding.getNullDefault) and when I turn that off, the exception is gone.

I've attached an MRE project now: Test.zip

@srikanth-sankaran
Copy link
Contributor

@stephan-herrmann Another problem scenario where org.eclipse.jdt.internal.compiler.lookup.ClassScope.hasDefaultNullnessFor(ClassScope.java:1737) triggers a symptom that is different from #1007 and cousins

@stephan-herrmann
Copy link
Contributor

Will be fixed by the next iteration in #1067

stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 18, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotation details

Common point-fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces part of the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 18, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotation details

Common point-fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces part of the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 21, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 21, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 21, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 21, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Reverts/replaces the fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 23, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Replaces the reverted fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 23, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Replaces the reverted fix from:
* eclipse-jdt#630
stephan-herrmann added a commit to stephan-herrmann/eclipse.jdt.core that referenced this issue May 24, 2023
(regression 2023-03)

Avoids any risky ahead-of-time resolving of annotations

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986

Replaces the reverted fix from:
* eclipse-jdt#630
stephan-herrmann added a commit that referenced this issue Jul 2, 2023
…ssion 2023-03) (#1077)

Avoids any risky ahead-of-time resolving of annotations
+ In ClassScope.findSuperType() remove the early 
  hasDefaultNullnessFor() from #630
+ In ReferenceBinding.implementsInterface() remove ahead-of-time
  resolving from from #630
+ TypeReference.internalResolveType() should never resolve any
  annotations when not ready
  - Readiness is determined by (tagBits & EndHierarchyCheck) != 0.
+ Scope.hasDefaultNullnessForType, when not ready, always answers false
  to leave a clean slate for a later phase to consider null annotations.

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work
+ Starting from LookupEnvironment.completeBindings() a new phase has
  been introduced which may safely assume that all type hierarchies are
  fully completed to avoid all out-of-order processing
+ Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations():
  - complete the initialization of tagBits relating to all kinds
    of annotations
  - traverse all superclass, superInterfaces and memberTypes links to
    update resolved bindings with information from anntations
+ 2nd level implementation is in TypeReference.updateWithAnnotations()
  which will resolve annotations and possibly update .resolvedType
  with that information

Common fix for these problems:
* #1007
* #854
* redhat-developer/vscode-java#3076
* #986
* #476

Replaces the reverted fix from:
* #630

Remove remnants of deferred checks from Bug 434570 et al see  #1074

Also:
+ additional tweak to help completion to find fields
+ Test isolation: fix deletion of jar and classpath entry
+ Test isolation: recover currentProject when run in a suite
+ Temp disable tests affected by #1201
@stephan-herrmann
Copy link
Contributor

Resolved via #1077

mpalat pushed a commit to mpalat/eclipse.jdt.core that referenced this issue Jul 6, 2023
…ssion 2023-03) (eclipse-jdt#1077)

Avoids any risky ahead-of-time resolving of annotations
+ In ClassScope.findSuperType() remove the early 
  hasDefaultNullnessFor() from eclipse-jdt#630
+ In ReferenceBinding.implementsInterface() remove ahead-of-time
  resolving from from eclipse-jdt#630
+ TypeReference.internalResolveType() should never resolve any
  annotations when not ready
  - Readiness is determined by (tagBits & EndHierarchyCheck) != 0.
+ Scope.hasDefaultNullnessForType, when not ready, always answers false
  to leave a clean slate for a later phase to consider null annotations.

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work
+ Starting from LookupEnvironment.completeBindings() a new phase has
  been introduced which may safely assume that all type hierarchies are
  fully completed to avoid all out-of-order processing
+ Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations():
  - complete the initialization of tagBits relating to all kinds
    of annotations
  - traverse all superclass, superInterfaces and memberTypes links to
    update resolved bindings with information from anntations
+ 2nd level implementation is in TypeReference.updateWithAnnotations()
  which will resolve annotations and possibly update .resolvedType
  with that information

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986
* eclipse-jdt#476

Replaces the reverted fix from:
* eclipse-jdt#630

Remove remnants of deferred checks from Bug 434570 et al see  eclipse-jdt#1074

Also:
+ additional tweak to help completion to find fields
+ Test isolation: fix deletion of jar and classpath entry
+ Test isolation: recover currentProject when run in a suite
+ Temp disable tests affected by eclipse-jdt#1201
robstryker pushed a commit to robstryker/eclipse.jdt.core that referenced this issue Jul 18, 2024
…ssion 2023-03) (eclipse-jdt#1077)

Avoids any risky ahead-of-time resolving of annotations
+ In ClassScope.findSuperType() remove the early 
  hasDefaultNullnessFor() from eclipse-jdt#630
+ In ReferenceBinding.implementsInterface() remove ahead-of-time
  resolving from from eclipse-jdt#630
+ TypeReference.internalResolveType() should never resolve any
  annotations when not ready
  - Readiness is determined by (tagBits & EndHierarchyCheck) != 0.
+ Scope.hasDefaultNullnessForType, when not ready, always answers false
  to leave a clean slate for a later phase to consider null annotations.

Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work
+ Starting from LookupEnvironment.completeBindings() a new phase has
  been introduced which may safely assume that all type hierarchies are
  fully completed to avoid all out-of-order processing
+ Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations():
  - complete the initialization of tagBits relating to all kinds
    of annotations
  - traverse all superclass, superInterfaces and memberTypes links to
    update resolved bindings with information from anntations
+ 2nd level implementation is in TypeReference.updateWithAnnotations()
  which will resolve annotations and possibly update .resolvedType
  with that information

Common fix for these problems:
* eclipse-jdt#1007
* eclipse-jdt#854
* redhat-developer/vscode-java#3076
* eclipse-jdt#986
* eclipse-jdt#476

Replaces the reverted fix from:
* eclipse-jdt#630

Remove remnants of deferred checks from Bug 434570 et al see  eclipse-jdt#1074

Also:
+ additional tweak to help completion to find fields
+ Test isolation: fix deletion of jar and classpath entry
+ Test isolation: recover currentProject when run in a suite
+ Temp disable tests affected by eclipse-jdt#1201
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needinfo Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants