Community
Participate
Working Groups
I200411090800 public class K { void a() { /*press Ctrl+Shift+Down here*/ } } void m() {} } Error Nov 10, 2004 13:06:05.553 The command for the key you pressed failed java.lang.NullPointerException at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.firstOpeningBraceOffset(GoToNextPreviousMemberAction.java:224) at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.getOffset(GoToNextPreviousMemberAction.java:214) at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.addMemberOffsetList(GoToNextPreviousMemberAction.java:207) at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.createOffsetArray(GoToNextPreviousMemberAction.java:200) at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.getNewSelectionRange(GoToNextPreviousMemberAction.java:135) at org.eclipse.jdt.internal.ui.javaeditor.selectionactions.GoToNextPreviousMemberAction.run(GoToNextPreviousMemberAction.java:102) at org.eclipse.jface.action.Action.runWithEvent(Action.java:988) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:188) at org.eclipse.ui.internal.commands.Command.execute(Command.java:130) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:445) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:724) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:767) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:536) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$2(WorkbenchKeyboard.java:479) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$1.handleEvent(WorkbenchKeyboard.java:221) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:752) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:817) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:827) at org.eclipse.swt.widgets.Control.traverse(Control.java:2696) at org.eclipse.swt.widgets.Control.translateTraversal(Control.java:2677) at org.eclipse.swt.widgets.Composite.translateTraversal(Composite.java:799) at org.eclipse.swt.widgets.Display.translateTraversal(Display.java:3241) at org.eclipse.swt.widgets.Display.filterMessage(Display.java:766) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2444) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1537) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1508) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:277) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:144) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:102) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:704) at org.eclipse.core.launcher.Main.main(Main.java:688)
- iInitializer.getSourceRange() returns a SourceRange with offset=36, length=0 - the getSource() and getSourceRange() API say null is returned when there's no source but since the parent has the source and getSourceRange() returns not null I'd expect to get non-null value for iInitializer.getSource()
This is a recovery problem. Start and end of initializer are not correctly initialized when inserted to fix compilation issue.
Created attachment 15834 [details] This patch seems to fix the problem...
Created attachment 15835 [details] Regression test add to CompilationUnitTests
David, Running JDT/Core tests shows that the fix is not valid. You're surely knows why that source range length needs to be equals to 0 for the inserted initializer... May you comment this change? Thx
Dani, After further investigation, I'm not really convinced with your explanation. The source range used by GoToNextPreviousMemberAction comes from private method createSourceRange() which never returns null! So, you do not rely on ISourceReference#getSourceRange() result to know whether there's source or not... I return this bug in your land as you really need to change implementation to avoid this NPE in JDT/UI. However, I agree that looking at implementation, Javadoc is not really accurate. So, feel free to open a new bug to make us change either the Javadoc or the behavior of ISourceReference#getSourceRange() method...
My explanation did not mention where the source range came from ;-) and I think it's not relevant in this scenario. I commented what I saw in the debugger: - I have an IType which has source (the action is only enabled in such a case) - J Core gives me the (1) initializer (by calling IType.getInitializers()) - the initializer returns a source range but returns null for getSource() Dirk and I would expect that if X (e.g. IType in our case) has source then all the children have source as well (at least the empty string). getSourceRange() already works like that.
So, if I've well understood, you're expecting that IInitializer#getSource() does not return null in this case (like its parent in fact...). Am i right?
Yes that is our expectation. Same as we expect getSourceRange() not to return null when the parent already returned a source range.
This is a recovery problem but the fix inside comment 3 is not correct.
David, I already discarded my fix by myself in comment 5... ;-)
*** Bug 78305 has been marked as a duplicate of this bug. ***
I've released regression test in CompilationUnitTests by, of course, I've desactivated it...
Created attachment 16009 [details] Correct patch
Fixed and test added ASTConverterTestAST3_2#test0577() CompilationUnitTests#testBug78275()
Verified for 3.1 M4 using build I200412140800.
