NullPointerException during Java Search

[ptziegler]

This happens both in the 2024-12 and the 2024-09, but likely also in older versions of the Eclipse IDE.

(Plain stack trace for readability)

java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.internal.compiler.lookup.TypeBinding.leafComponentType()" because "this.resolvedType" is null
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveAnnotations(TypeReference.java:696)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.updateWithAnnotations(TypeReference.java:656)
	at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.updateWithAnnotations(SingleTypeReference.java:164)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.updateParameterizedTypeWithAnnotations(TypeReference.java:662)
	at org.eclipse.jdt.internal.compiler.ast.ParameterizedQualifiedTypeReference.updateWithAnnotations(ParameterizedQualifiedTypeReference.java:538)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.updateWithAnnotations(TypeDeclaration.java:1981)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.updateSupertypesWithAnnotations(TypeDeclaration.java:1947)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.updateSupertypesWithAnnotations(TypeDeclaration.java:1961)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.updateSupertypesWithAnnotations(TypeDeclaration.java:1961)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.integrateAnnotationsInHierarchy(CompilationUnitScope.java:443)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment$CompleteTypeBindingsSteps.perform(LookupEnvironment.java:195)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:565)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1326)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1388)
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1508)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:143)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:276)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:620)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:677)
	at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:178)
	at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

This is the reference causing the exception:

Class scope:

Method scope:

I believe that this issue is caused by the Nullable annotations of the Checker Framework used by Guava. The packages are not specified in the bundle manifest, it is not included in the target platform/Eclipse installation and therefore not in the classpath.

[jukzi]

cc @stephan-herrmann because of @Nullable

[stephan-herrmann]

@ptziegler could you please provide a self-contained reproducer as text, so we can copy-and-paste it to a unit test?

It would also be good to know if you have annotation-based null analysis enabled and with which details.

Thanks

[ptziegler]

@ptziegler could you please provide a self-contained reproducer as text, so we can copy-and-paste it to a unit test?

It would also be good to know if you have annotation-based null analysis enabled and with which details.

Thanks

package test;

import java.io.File;

public class Test {
	public static Object create(File f) {
		return null;
	}
}

recording.webm

The project is a simple Plugin with only Guava as a dependency:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: TestProject
Bundle-SymbolicName: TestProject
Bundle-Version: 1.0.0.qualifier
Require-Bundle: com.google.guava;bundle-version="33.3.1"
Automatic-Module-Name: TestProject
Bundle-RequiredExecutionEnvironment: JavaSE-21

This is from a fresh installation, so I don't think any annotations are enabled.

[ptziegler]

As a side note: I don't think this exception has anything to do with the null-analysis. It just happens to be the @Nullable annotation because Guava doesn't explicitly require it, even though the Checker Framework gave it a runtime retention policy.

[stephan-herrmann]

I can reproduce, thanks.

[stephan-herrmann]

Internally, at the time of the exception we already recorded these problems:

2 PROBLEM(s) detected 
	 - Pb(2) Nullable cannot be resolved to a type
	 - Pb(327) The hierarchy of the type NeverSuccessfulListenableFutureTask is inconsistent

The same problems are also in the list of errors if I import com.google.common.util.concurrent.MoreExecutors into the test project. But while compilation raises these errors, I don't see the NPE during compilation, only during search.

[stephan-herrmann]

Here's the reason for the hierarchy problem: com.google.common.util.concurrent.internal.InternalFutureFailureAccess cannot be resolved as a supertype for com.google.common.util.concurrent.AbstractFuture.
Indeed guava does not contain that ...concurrent.internal package but only has an Import-Package for it, which PDE doesn't resolve, nor complain about.

[stephan-herrmann]

events contributing to the NPE:

• some lookup of com.google.common.util.concurrent.internal.InternalFutureFailureAccess yields a MissingTypeBinding
  • it has HierarchyHasProblems in its tagBits
• resolving supertypes of InCompletionOrderFuture finds:
  • its immediate super AbstractFuture as a BinaryTypeBinding
  • the super's parent is the MissingTypeBinding from above
  • at this point the flag HierarchyHasProblems is propagated down into AbstractFuture
• later supertypes of NeverSuccessfulListenableFutureTask are resolved
  • we find the super class AbstractFuture
  • as AbstractFuture has HierarchyHasProblems resolution makes an early exit return null
  • this aborts other resolution of the current type reference, which is "AbstractFuture.TrustedFuture<@Nullable Void>"
  • as a result no resolution is ever attempted for the type argument "@Nullable Void".
• during phase INTEGRATE_ANNOTATIONS_IN_HIERARCHY we assume that type argument to be resolved => NPE

I believe the difference between search and compilation lies in the order of events: when directly resolving the hierarchy of NeverSuccessfulListenableFutureTask the missing grand-parent does not set hasCycle. Only when AbstractFuture has been tagged HierarchyHasProblems by a previous hierarchy lookup then detectHierarchyCycle() answers true, causing the early exit.

It will be a bit tricky to create a unit test reproducing the bad sequence of events.

The fix will probably just be adding a check for HierarchyHasProblems in TypeDeclaration.updateSupertypesWithAnnotations()

[stephan-herrmann]

For completeness:

As a side note: I don't think this exception has anything to do with the null-analysis. It just happens to be the @Nullable annotation because Guava doesn't explicitly require it, even though the Checker Framework gave it a runtime retention policy.

Right, it's not related to null analysis, any annotation in that position will do, and the not-found type causing the NPE is neither @Nullable nor Void but InternalFutureFailureAccess.