Community
Participate
Working Groups
Build Identifier: It appears that my custom library isn't being marked as a binary type, so when resolve tries to getJavaScriptUnit() on line 532 of HeirarchyResolver, it returns null (CLASS_FILE instead of JAVASCRIPT_UNIT). java.lang.NullPointerException at org.eclipse.wst.jsdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:525) at org.eclipse.wst.jsdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:126) at org.eclipse.wst.jsdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:152) at org.eclipse.wst.jsdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:290) at org.eclipse.wst.jsdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:979) at org.eclipse.wst.jsdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.wst.jsdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:742) at org.eclipse.wst.jsdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:802) at org.eclipse.wst.jsdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:557) at org.eclipse.wst.jsdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:533) at org.eclipse.wst.jsdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:119) at org.eclipse.wst.jsdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:79) at org.eclipse.wst.jsdt.internal.corext.util.SuperTypeHierarchyCache.getMethodOverrideTester(SuperTypeHierarchyCache.java:88) at org.eclipse.wst.jsdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:158) at org.eclipse.wst.jsdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:126) at org.eclipse.wst.jsdt.ui.OverrideIndicatorLabelDecorator.decorate(OverrideIndicatorLabelDecorator.java:221) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Digging deeper, I discovered that the reason the SourceTypeElementInfo isn't "binary" is because CompilationUnitStructureRequestor.enterType is called twice. The first time through, no problem, parentHandle IS an instance of ClassFile, so it's marked binary... and then a handle to the SourceTypeElementInfo is tacked onto the handleStack. The second time through it is this handle that is checked, and isn't a ClassFile, so the "isBinary" is left false. Why is it being called twice? I didn't dig THAT deeply. PS: My LibraryInitializer's getSuperClasses is never called... could be related. Reproducible: Always
