Community
Participate
Working Groups
class Y { public void bar2(p.Foo f1) { return; } public void bar2(q.Foo f1) { return; } public void bar3(Z z) {return; } public void bar3(Z2 z) {return;} } interface I { void fooI(Y y); } interface I2 { void fooI(String n);} class Z {} class Z2 {} public class X { void foo() { Y y = new Y(); y.bar2(new p.Foo()); // Select bar2 and click F3. A dialogue box comes up. // ^^^^ y.bar2(new q.Foo()); // Select bar2 and click F3. A dialogue box comes up. // ^^^^ y.bar3(new Z()); // F3 on bar3 leads to the correct method definition y.bar3(new Z2()); // F3 on bar3 leads to the correct method definition } } --- package p; public class Foo { } --- package q; public class Foo { } --- Similar behavior is seen with Juno as well. Thanks
(In reply to shankha banerjee from comment #0) > y.bar2(new p.Foo()); // Select bar2 and click F3. A dialogue box comes up. > // ^^^^ > y.bar2(new q.Foo()); // Select bar2 and click F3. A dialogue box comes up. > // ^^^^ What's in the box?
Created attachment 245869 [details] Dialogue Box Screenshot Hi Stephan, The dialogue box shows both the overloaded methods. Thanks
This looks by design: This is the call stack: OS.WaitMessage() line: not available [native method] Display.sleep() line: 4701 ElementListSelectionDialog(Window).runEventLoop(Shell) line: 833 ElementListSelectionDialog(Window).open() line: 808 ElementListSelectionDialog(AbstractElementListSelectionDialog).open() line: 449 SelectionConverter.selectJavaElement(IJavaElement[], Shell, String, String) line: 353 OpenAction.run(ITextSelection) line: 174 OpenAction(SelectionDispatchAction).dispatchRun(ISelection) line: 279 OpenAction(SelectionDispatchAction).run() line: 251 OpenAction(Action).runWithEvent(Event) line: 519 ActionHandler.execute(ExecutionEvent) line: 122 The javadoc on SelectionConvereter.selectJavaElement says: /** * Shows a dialog for resolving an ambiguous Java element. Utility method that can be called by subclasses. * * @param elements the elements to select from * @param shell the parent shell * @param title the title of the selection dialog * @param message the message of the selection dialog * @return returns the selected element or <code>null</code> if the dialog has been cancelled */ Why that situation should be considered ambiguous is unclear to me though. Passing to UI for investigation. At a quick glance, I don't see anything wrong with the selection element computed by Core, but if we have a finger in the pie, please pass it back.
From the code in comment #0, select "bar2" in the following line: y.bar2(new p.Foo()); In the JavaElement View, press "Set input from current editor's selection (codeSelect)". The result shows two ResolvedSourceMethod with parameter type as "Qp.Foo;" and "Qq.Foo;" respectively. Since the parameter is "new p.Foo()", only one ResolvedSourceMethod should be returned by ICodeAssist.codeSelect i.e. the one with parameter type "Qp.Foo;" (and not "Qq.Foo;"). The code where ICodeAssist.codeSelect is invoked by UI is: SelectionConverter.codeResolve(IJavaElement input, ITextSelection selection) which returns 2 Java elements for "bar2" in y.bar2(new p.Foo()); Hence, both the results are displayed to the user through the "Open" dialog. Looks like a problem in codeSelect.
There are several versions of acceptSourceMethod() methods in SelectionRequestor. In one of them, line: 576, we aren't making use of the parameterPackageNames that is supplied. In fact, it looks like there are other methods that ignore this parameter too. So, it looks like we have been living with this for some time. If someone is interested in seeing this fixed, please provide a patch.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
