Community
Participate
Working Groups
Got the following NPE trying to search for references to a method with I20200113-1800. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.hasMethodWithNumArgs(SourceTypeBinding.java:2276) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.applyCloseableClassWhitelists(ReferenceBinding.java:2107) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectSuperclass(ClassScope.java:977) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.connectTypeHierarchy(ClassScope.java:1117) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:367) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:584) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:209) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:342) at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:276) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:547) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:619) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:448) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:521) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:874) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:672) at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:129) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:170) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:323) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1319) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:736) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:795) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:746) at org.eclipse.jdt.internal.core.search.IndexSelector.getFocusedElementsAndTypes(IndexSelector.java:166) at org.eclipse.jdt.internal.core.search.IndexSelector.initializeIndexLocations(IndexSelector.java:227) at org.eclipse.jdt.internal.core.search.IndexSelector.getIndexLocations(IndexSelector.java:298) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.selectIndexURLs(JavaSearchParticipant.java:136) at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:86) at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:59) at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:177) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:234) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:595) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:178) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:95) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) Not sure if this is specific to org.eclipse.osgi project or not. Seems like it just started happening with the latest I-Build, but could also be some changes to the project settings recently. Steps to reproduce: 1) clone https://git.eclipse.org/r/equinox/rt.equinox.framework.git 2) import org.eclipse.osgi project located at bundles/org.eclipse.osgi 3) Open the type org.eclipse.osgi.storage.Storage and select the createStorage(EquinoxContainer) method and search with References->Project (although search in workspace does the same). I try to search for methods in other projects and they seem to work, so something specific with org.eclipse.osgi.
Can reproduce. Luckily I'm always running with opened debug port, so in the debugger I see this.scope = org.eclipse.osgi.storage.url.reference.ReferenceInputStream this.scope.referenceContext = TypeDeclaration for ReferenceInputStream this.scope.referenceContext.methods = null :-( The change in org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.hasMethodWithNumArgs(char[], int) is coming from bug 558759.
New Gerrit change created: https://git.eclipse.org/r/155968
Thanks, Tom, for the precise steps. While technically legal, a resource implementation with no methods would be a bit of a surprise. The real reason, however, for a TypeDeclaration with no methods was: the hierarchy resolver pulls in additional types via the SourceTypeConverter without even creating the AST for any methods (only below 1.8 that is. I assume at 1.8+ we need to find any contained lambdas or such ...). Not finding any methods implies that our resource leak analysis is less precise, but during hierarchy resolving we don't use the analysis result anyway :)
@Manoj, @Jay, after my surprise to find no type java.io.Closeable in jclMin1.7.jar I for a second considered to add that type, but since jclMin* cannot be extended currently, I had to abandon that thought and rolled my own j.i.Closeable inside the test. Not perfect.
Gerrit change https://git.eclipse.org/r/155968 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9eac2d764cbec2160db1c91a3a05341846688165
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/155968 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=9eac2d764cbec2160db1c91a3a05341846688165 Released to master for 4.15 M3
(In reply to Stephan Herrmann from comment #4) > @Manoj, @Jay, after my surprise to find no type java.io.Closeable in > jclMin1.7.jar I for a second considered to add that type, but since jclMin* > cannot be extended currently, I had to abandon that thought and rolled my > own j.i.Closeable inside the test. Not perfect. I suppose, we can live with that. Hopefully I can find some time to get to that other problem and come up with a generic solution.
Verified on I20200116-0330. Thanks for the quick turnaround!
