Community
Participate
Working Groups
Build ID: 3.5M6 Steps To Reproduce: 1. Open org.eclipse.core.internal.resources.Resource.class (resources plugin should NOT be imported as *source* project in the workspace) 2. Ctrl+Mouse click on any method declaration 3. NPE: java.lang.NullPointerException at org.eclipse.jdt.internal.ui.javaeditor.JavaElementImplementationHyperlink.open(JavaElementImplementationHyperlink.java:164) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$LinkListInformationControl.openSelectedLink(MultipleHyperlinkPresenter.java:319) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$LinkListInformationControl.access$1(MultipleHyperlinkPresenter.java:314) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$3.widgetSelected(MultipleHyperlinkPresenter.java:275) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) Related source code expects to see resolved type binding, which is null: ITypeBinding binding= expression.resolveTypeBinding(); elem= binding.getJavaElement();
Andrei, I can see that a NPE is possible from the code but I cannot reproduce using your steps as I understood them: 1. start fresh workspace 2. import org.eclipse.core.resources as binary (not as source) 3. open type 'Resource' 4. click on a method declaration OR: 1. start fresh workspace 2. import a project that require org.eclipse.core.resources (org.eclipse.core.resources not explicitly imported) 3. open type 'Resource' 4. click on a method declaration Can you provide more detailed steps?
Raksha, please protect all calls in the open method that can return against NPE.
Created attachment 128909 [details] Patch with added null checks.
Thanks for the patch Raksha. Committed to HEAD Available in builds > N20090315-2000. Andrei, it would still be good to get a test case.
> Created an attachment (id=128909) [details] > Patch with added null checks. I removed the "if (parent != null)" check in HEAD, since it's redundant (all branches of the nested if-else statement do an instanceof check first). Also refactored the null check for parentTypeBinding a bit (do it only once) and used JdtFlags.isAbstract(..) to simplify the test in the search requestor. I could reproduce with these steps: 1. start fresh workspace 2. org.eclipse.core.resources as binary 3. remove target platform 4. open type 'Resource' 5. press Ctrl and click Open Implementation on the declaration of the accept(..) method Verified that the problem is gone in HEAD. We open the quick type hierarchy now, because the type is full of (invisible) compile errors due to the missing dependencies.
