Bug 302470 - [api] ProblemLocation#getProblemArguments() must not return null
Summary: [api] ProblemLocation#getProblemArguments() must not return null
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.6 M7   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-10 13:01 EST by Olivier Thomann CLA
Modified: 2010-03-15 05:50 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2010-02-10 13:01:21 EST
Using eclipse.buildId=I20100128-1731
java.version=1.6.0_18-ea
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_CA
Command-line arguments:  -os win32 -ws win32 -arch x86 -console,

java.lang.NullPointerException
	at org.eclipse.jdt.internal.junit.ui.JUnitQuickFixProcessor.getAddAssertImportProposals(JUnitQuickFixProcessor.java:122)
	at org.eclipse.jdt.internal.junit.ui.JUnitQuickFixProcessor.getCorrections(JUnitQuickFixProcessor.java:111)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionCollector.safeRun(JavaCorrectionProcessor.java:374)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.run(JavaCorrectionProcessor.java:336)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor$SafeCorrectionProcessorAccess.process(JavaCorrectionProcessor.java:332)
	at org.eclipse.jdt.internal.ui.text.correction.JavaCorrectionProcessor.collectCorrections(JavaCorrectionProcessor.java:461)
	at org.eclipse.jdt.internal.ui.text.java.hover.ProblemHover$ProblemInfo.getJavaAnnotationFixes(ProblemHover.java:221)
	at org.eclipse.jdt.internal.ui.text.java.hover.ProblemHover$ProblemInfo.getCompletionProposals(ProblemHover.java:195)
	at org.eclipse.jdt.internal.ui.text.java.hover.AbstractAnnotationHover$AnnotationInformationControl.deferredCreateContent(AbstractAnnotationHover.java:280)
	at org.eclipse.jdt.internal.ui.text.java.hover.AbstractAnnotationHover$AnnotationInformationControl.setInput(AbstractAnnotationHover.java:186)
	at org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(AbstractInformationControlManager.java:1170)
	at org.eclipse.jface.text.AbstractInformationControlManager.presentInformation(AbstractInformationControlManager.java:1139)
	at org.eclipse.jface.text.AbstractHoverInformationControlManager.presentInformation(AbstractHoverInformationControlManager.java:902)
	at org.eclipse.jface.text.TextViewerHoverManager.doPresentInformation(TextViewerHoverManager.java:243)
	at org.eclipse.jface.text.TextViewerHoverManager$5.run(TextViewerHoverManager.java:233)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3959)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3580)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2407)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2371)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
	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:367)
	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:611)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1363)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1339)


Steps to reproduce:
1) In a new java project setup to accept generics (1.5 or above) add the following types:
import java.util.Collection;

public interface Task<T> {
	Collection<TaskListener<T>> getListeners();
}


public interface TaskListener<T> {
	void taskFailed(Task task, Exception e);
}

and:

import java.util.List;

public class X {
	public static void main(String[] args) {
		Exception e = new Exception();
		List<Task<?>> tasks = null;
 		for (final Task<?> task : tasks) {
			for (final TaskListener<?> listener : task.getTaskListeners()) {
				listener.taskFailed(task, e);
			}
		}
	}
}
2) An error is reported against "task.getTaskListeners()". Hovering over it creates the reported stack trace.
Comment 1 Markus Keller CLA 2010-02-11 10:16:31 EST
I could not reproduce the problem with the hover in HEAD. But when I selected the problem in the Problems view, I ran into bug 302587.

If you could extend the steps so that I can reproduce the problem in the hover, that would be great. Otherwise, I'll just protect the code against null.
Comment 2 Olivier Thomann CLA 2010-02-11 13:58:56 EST
I could not reproduce the NPE using HEAD :-(.
Comment 3 Olivier Thomann CLA 2010-02-11 14:40:08 EST
Looking at the code the problem should not happen if the problem has arguments, but since there is at least one path that can return null when decoding the arguments, a null check might be a good idea.
Note that technically speaking null should not be retrieved as the format of the arguments inside the marker should be encoded in a way to be decoded without errors.
Comment 4 Olivier Thomann CLA 2010-02-11 15:14:49 EST
This is a consequence of bug 302587.
Adding a null check would be good to prevent decoding issues.

I could get the NPE in the console if I remove the fix for bug 302587.
Comment 5 Markus Keller CLA 2010-03-08 07:05:34 EST
org.eclipse.jdt.ui.text.java.IProblemLocation#getProblemArguments() does not specify that it can return null, but ProblemLocation does not enforce that.
Comment 6 Dani Megert CLA 2010-03-15 05:50:10 EDT
Fixed in HEAD.
Available in builds > N20100314-2000.