Community
Participate
Working Groups
Start with a brand new workspace. The first thing you do is import a project interchange file. You get a NPE during the auto-build. I think it's a static field initialization order problem, since the NPE is on a line that is pointing to a static final field of another class (Binding.NO_SUPERINTERFACES) but the of that field is null. Please email me if you'd like the project interchange file. java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.findSuperTypeErasingTo(ReferenceBinding.java:616) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:947) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1094) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:353) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:696) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:515) at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:113) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:133) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1235) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:779) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:700) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:652)
Would it be possible to get a test case to reproduce this issue? Thanks.
Also what is the build ID ?
pls reopen when steps and required info is made available
Got testcase from Mindaugas.
Cannot reproduce any issue with latest. Please provide accurate steps, including what you were doing to get the exception, build ID, installed JRE ...
Mindaugas said it is based on Eclipse RC4
cc'ing kevin
Found using: WinXP SP2 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060425 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060425 (JIT enabled) J9VM - 20060424_06327_lHdSMR JIT - 20060420_1800_r8 GC - 20060412_AA) JCL - 20060425 Eclipse 3.2RC4 I also tried the updating jdt to jdt-core (v669) and the problem was still there. After import, it happens during every build, even after which to Java perspective and creating a new java project.
I'll update this PR if we think we'll need this fixed for 3.2.0, but the current thinking is that 3.2.1 will be ok.
Offending line is: public ReferenceBinding findSuperTypeErasingTo(int wellKnownErasureID, boolean erasureIsClass) { // do not allow type variables to match with erasures for free if (this.id == wellKnownErasureID || (!isTypeVariable() && erasure().id == wellKnownErasureID)) return this; ReferenceBinding currentType = this; // iterate superclass to avoid recording interfaces if searched supertype is class if (erasureIsClass) { while ((currentType = currentType.superclass()) != null) { if (currentType.id == wellKnownErasureID || (!currentType.isTypeVariable() && currentType.erasure().id == wellKnownErasureID)) return currentType; } return null; } ReferenceBinding[] interfacesToVisit = null; int nextPosition = 0; do { ReferenceBinding[] itsInterfaces = currentType.superInterfaces(); if (itsInterfaces != Binding.NO_SUPERINTERFACES) { if (interfacesToVisit == null) { interfacesToVisit = itsInterfaces; >>>>> nextPosition = interfacesToVisit.length; which would indicate 'itsInterfaces' is still null at this stage. In theory, it should be at least an empty array. Smells like type hierarchy computation is not triggering supertype connecting properly.
Suspecting type hierarchy computation to try to be more resilient than it needs. Enabling hierarchy trace, found the following when manually asking for a full type hierarchy (ctrl-H) on ActionServlet: CREATING TYPE HIERARCHY [Thread[Worker-0,5,main]] on type ActionServlet [in ActionServlet.class [in org.apache.struts.action [in WebContent/WEB-INF/lib/struts.jar [in StudioPerf14]]]] org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:93) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1768) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3430) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:47) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveUnresolvedType(BinaryTypeBinding.java:138) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:907) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.findSuperClass(HierarchyResolver.java:157) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.reportHierarchy(HierarchyResolver.java:460) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:712) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:199) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:306) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:129) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1235) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:779) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:877) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:896) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:866) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(TypeHierarchyLifeCycle.java:118) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh(TypeHierarchyLifeCycle.java:157) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.doRestoreInBackground(TypeHierarchyViewPart.java:1506) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.access$9(TypeHierarchyViewPart.java:1505) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart$15.run(TypeHierarchyViewPart.java:1491) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:93) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1768) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3430) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:47) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveUnresolvedType(BinaryTypeBinding.java:138) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:907) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.findSuperClass(HierarchyResolver.java:157) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.reportHierarchy(HierarchyResolver.java:460) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:712) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:199) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:321) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:129) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1235) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:779) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:877) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:896) at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:866) at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(TypeHierarchyLifeCycle.java:118)CREATED TYPE HIERARCHY in 16781ms Focus: ActionServlet [in ActionServlet.class [in org.apache.struts.action [in WebContent/WEB-INF/lib/struts.jar [in StudioPerf14]]]] Super types: Sub types:
What we see is that some AbortCompilation got raised due to some incomplete classpath (there are some buidpath problems). Instead of stopping on these exceptions, the hierarchy resolver still tries to infer more data, and thus it enters code areas which are not met to be entered in such an inconsistent state. Questionning the need for resilience here... i.e. is it trying to recover more than it should ? Mindaugas: can you confirm presence of build path errors in your setup ? If so, does fixing them make the problem go away ?
Yes, there were build path problems in the project. (org.apache.struts.action.ActionServlet extends javax.servlet.http.HttpServlet which was missing from the classpath) Fixing this problem did make the new type hierarchy problem go away. Our use case is only trying to find out if a specific type extends ActionServlet. It would be nice if this would be possible to do in the presence of build path errors, but I understand if it's not possible and I think it's a fair limitation.
Created attachment 43580 [details] Proposed patch This patch also addresses bug 145500. Added null check for increased resilience to intermediate AbortCompilation (which hierarchies are swallowing for maximal resilience). Also ensured leaving supertype connecting code with at least an empty array, in case of AbortCompilation (double protection). Also improved resilience to missing supertype (bug 145500)
Sent JAR patch to Mindaugas. Please confirm whether this addresses your problem.
I tested the JAR, and it fixes the problem.
Mindaugas agreed to wait until 3.2.1 to get the fix. Added TypeHierarchyTests#testResilienceToMissingBinaries() Released for 3.2.1 inclusion
Jerome - pls verify
Released for 3.3 M1 while merging TARGET_321 in HEAD
Created attachment 44248 [details] Improved patch This patch (applied after Philippe's patch) fixes super type bindings before reporting the hierarchy. As a result, a type with a missing super class has null as the super class instead of Object. Thus the hierarchy appears correctly in the hierarchy view (instead of just showing Object).
Patch released for 3.3M1 in HEAD and released for 3.2.1 in TARGET_321 branch.
Verified for 3.3 M1 by user
Verified for 3.2.1 using build M20060908-1655
