Comment 1 Philipe Mulet 2006-01-24 07:29:13 EST

Hard to reproduce.
Also saw similar stack trace when searching for refs in workspace to java.util.List<E>

Comment 2 Philipe Mulet 2006-01-24 07:36:46 EST

My stack traces looked like:
!ENTRY org.eclipse.core.jobs 4 2 2006-01-24 13:36:29.075
!MESSAGE An internal error occurred during: "Java Search".
!STACK 0
java.lang.NullPointerException
        at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.initialize(ParameterizedTypeBinding.java:581)
        at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.<init>(ParameterizedTypeBinding.java:43)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createParameterizedType(LookupEnvironment.java:593)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:950)
        at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:298)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:521)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:170)
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:157)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.cacheBinaryType(MatchLocator.java:426)
        at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:67)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1492)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1014)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1055)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1173)
        at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:206)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:491)
        at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:532)
        at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:139)
        at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:94)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)

Comment 3 Philipe Mulet 2006-01-24 07:39:10 EST

Note that the NPE would be caused by a null type argument when creating a parameterized binary type (from decoding binary signature).

Comment 4 Philipe Mulet 2006-01-24 09:27:44 EST

Test case is: have tools.jar (1.5) on the build path, and search references to java.util.List. It finds one in tools.jar within file: 
com/sun/tools/javac/util/List$3

When caching the binary type, it fails decoding portion of the generic signature:
Ljava/lang/Object;Ljava/util/Iterator<TA;>;
i.e. decoding: Ljava/util/Iterator<TA;>;

It cannot rebind the type argument TA; properly, as local type doesn't seem to point to an enclosing type.

Comment 5 Philipe Mulet 2006-01-24 09:31:28 EST

Problem only arises in 1.5, when decoding local types reference to enclosing type parameters. Olivier suggested using the enclosingMethod attribute to reach the enclosing type.

Comment 6 Philipe Mulet 2006-01-24 10:13:20 EST

The NPE is a regression from past behavior. A bogus length check got added as part of support for DOM AST in error reporting for ProblemReporter#undefinedTypeVariableSignature(...)
which made the null scenario reachable, when it should have aborted from the resolution.

This explains the introduced NPE, as opposed to silent failure, but still we should be able to rebind properly enclosing type parameter from binary local types.

Comment 7 Jerome Lanneluc 2006-01-24 10:33:53 EST

HierarchyResolver#resolve(Openable[] openables, HashSet localTypes, IProgressMonitor monitor) should not resolved fields and methods when caching a binary type (line 607).

Comment 8 Philipe Mulet 2006-01-24 10:39:57 EST

jerome - pls open a separate issue for the resolver optimization.

The original issue can be reproduced by search as well, and the scenario should legitimally be supported.

Comment 9 Philipe Mulet 2006-01-24 13:20:49 EST

When connecting binaries for: new Z<A,C>()
it should be able to find enclosing method type parameters... which means it needs to cycle through enclosingMethod/Types, not just types.

public class Z<A,B> {
 
 void foo() {
  new Object() {
   <C> void bar() {
    new Z<A,C>(){};
   }
  };
 }
}

Comment 10 Olivier Thomann 2006-01-24 13:23:55 EST

Another test case:
public class Z<A,B> {
 
 void foo() {
  new Object() {
   void bar() {
    new Z<A, B>(){};
   }
  };
 }
}

and:
public class Z<A,B> {
 
 void foo() {
  new Object() {
   <C> void bar() {
    new Z<A,C>(){};
   }
  };
 }
}

In both cases we must be able to connect the type parameters.
In the first case, this requires the enclosing type for the anonymous type not being null.
The second case requires to go through the enclosing method first.

Comment 11 Olivier Thomann 2006-01-24 13:44:39 EST

Kent,

I released a fix to properly get the enclosing type from an anonymous type binding (even if it is a binary type binding). Before we would return null. Now we return the inner most enclosing type.

Comment 12 Jerome Lanneluc 2006-01-24 16:20:52 EST

(In reply to comment #8)
> jerome - pls open a separate issue for the resolver optimization.
> 
entered bug 125067

Comment 13 Kent Johnson 2008-04-24 16:26:44 EDT

Olivier - so what is left to do with this ?

Comment 14 Jerome Lanneluc 2008-05-12 05:53:06 EDT

Please close if nothing is left. Otherwise defer.

Comment 15 Olivier Thomann 2008-12-02 12:45:13 EST

It looks ok now as far as I can say.

Comment 16 Kent Johnson 2009-02-23 14:29:08 EST

Do not believe there are any remaining issues with this bug.

Comment 17 Frederic Fusier 2009-03-09 12:38:22 EDT

Unfortunately, I still get a NPE using I20090309-0100:
java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421)
at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756)
at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2577)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.ensureRefreshedTypeHierarchy(TypeHierarchyLifeCycle.java:122)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.updateInput(TypeHierarchyViewPart.java:534)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyViewPart.setInputElement(TypeHierarchyViewPart.java:497)
at org.eclipse.jdt.internal.ui.util.OpenTypeHierarchyUtil.openInViewPart(OpenTypeHierarchyUtil.java:95)
at org.eclipse.jdt.internal.ui.util.OpenTypeHierarchyUtil.open(OpenTypeHierarchyUtil.java:72)
at org.eclipse.jdt.ui.actions.OpenTypeHierarchyAction.run(OpenTypeHierarchyAction.java:229)
at org.eclipse.jdt.ui.actions.OpenTypeHierarchyAction.run(OpenTypeHierarchyAction.java:179)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:278)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:250)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2393)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2357)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2209)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:499)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:492)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:556)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:511)
at org.eclipse.equinox.launcher.Main.run(Main.java:1284)
at org.eclipse.equinox.launcher.Main.main(Main.java:1260)
Caused by: java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.getEnclosingMethod(ClassFileReader.java:457)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:307)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:635)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:614)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:108)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:127)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.enclosingType(BinaryTypeBinding.java:646)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.<init>(BinaryTypeBinding.java:182)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:618)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:614)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:108)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:127)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.enclosingType(BinaryTypeBinding.java:646)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.<init>(BinaryTypeBinding.java:182)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:618)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:172)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:706)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:226)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:328)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:131)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1255)
at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:917)
at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:875)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(TypeHierarchyLifeCycle.java:133)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh(TypeHierarchyLifeCycle.java:172)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle$1.run(TypeHierarchyLifeCycle.java:113)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Root exception:
java.lang.NullPointerException
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.getEnclosingMethod(ClassFileReader.java:457)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:307)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:635)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:614)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:108)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:127)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.enclosingType(BinaryTypeBinding.java:646)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.<init>(BinaryTypeBinding.java:182)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:618)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:614)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:108)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:127)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.enclosingType(BinaryTypeBinding.java:646)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.<init>(BinaryTypeBinding.java:182)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:618)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheBinaryType(LookupEnvironment.java:172)
at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:706)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildForProject(IndexBasedHierarchyBuilder.java:226)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(IndexBasedHierarchyBuilder.java:328)
at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:131)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300)
at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1255)
at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:917)
at org.eclipse.jdt.internal.core.BinaryType.newTypeHierarchy(BinaryType.java:875)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(TypeHierarchyLifeCycle.java:133)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh(TypeHierarchyLifeCycle.java:172)
at org.eclipse.jdt.internal.ui.typehierarchy.TypeHierarchyLifeCycle$1.run(TypeHierarchyLifeCycle.java:113)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Comment 18 Olivier Thomann 2009-03-09 13:03:58 EDT

This is because we need to cache the enclosing method value. Once the constant pools offset are gone, we cannot initialize the enclosing method anymore.

Comment 19 Olivier Thomann 2009-03-09 13:06:53 EDT

Created attachment 128056 [details]
Proposed fix

Comment 20 Kent Johnson 2009-03-09 15:55:53 EDT

Released fix for 3.5M6

Was unable to produce a junit test for this case.

To verify, use this type with a 1.5 sun vm:

public class Test {
        void foo() {
                Comparable<Integer> comp;
        }
}

And open a hierarchy on Comparable

Comment 21 Frederic Fusier 2009-03-10 10:18:00 EDT

Verified for 3.5M6 using I20090310-0100.

Comment 22 Markus Keller 2009-08-06 06:57:56 EDT

*** Bug 285754 has been marked as a duplicate of this bug. ***

Comment 23 Olivier Thomann 2009-10-27 10:30:43 EDT

Last fix has been backported to 3.4 maintenance stream.