Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 123689

Summary:	[organize imports] Auto-import could be smarter
Product:	[Eclipse Project] JDT	Reporter:	Brian Cort <briancort>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	3.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Brian Cort

2006-01-12 17:42:41 EST

When I hit control-shift-m (auto-import) on an undefined type used in a method parameter, if there are multiple types with the same name then the add import option dialog prompts me to choose one. In this case, it should automatically choose the type that matches the parameter of the method it is being used for.

for example, if I have this:
something.setFoo(Foo.BLUE)

if there are two Foo classes defined in the workspace, it should know that I mean the Foo required by the method setFoo() on the class of object something. Obviously this fails if types with the same name extend each other, but that then the fallback is the current behaviour and let the user choose.

Apologies if this has been fixed in a version newer than 3.1 (what I'm using).

Comment 1 Jerome Lanneluc

2006-01-17 11:32:00 EST

Moving to JDT UI

Comment 2 Martin Aeschlimann

2006-01-18 04:50:11 EST

we can only do that if there is really ony one method matching. And I think it only works for Enums

Comment 3 Brian Cort

2006-01-18 11:03:41 EST

Martin, I believe you are misunderstanding my bug report, since it has nothing to do with enums.

Suppose I define the following classes:

package my.pkg1;
public class Color {
}

-----

package your.pkg2;
public class Color {
}

public class Thing {
  public void setColor(Color c) {} // <-- expects a your.pkg2.Color since its in the same package
}

------

And then suppose I'm working in another class in another package:

package other.pkg;
class CCCC {
  public CCCC() {
    your.pkg2.Thing thing = new your.pkg2.Thing();
    thing.setColor(new Color());
                         ^^----------------------------- cursor is HERE
  }
}

If I put the cursor where indicated and press Ctrl-Shift-M (auto-import), a dialog will come up asking whether I mean 'my.pkg.Color', 'your.pkg2.Color', 'java.awt.Color', etc. This is unnecessary since the only valid type for the method is 'your.pkg2.Color'.

This issue affects me on a daily basis as I interact with quite a few 2d and 3d libraries and they all define commonly named classes such as 'polygon, color', etc.

Thanks for your attention.

Comment 4 Martin Aeschlimann

2006-01-18 11:08:28 EST

ok, your're right

Comment 5 Brian Cort

2006-01-20 11:09:01 EST

I realized this bug could be generalized to include another case where import could be smarter. I'm not sure if this should be filed as a separate issue:

When defining a type in an assignment statement, the import should be automatic.

So extending my example from comment 3:

If your.pkg2.Thing had a method 'Color getColor() {...}

Then anywhere I type

Color c = new your.pkg2.Thing().getColor()

I should not need to select which Color I mean in the import dialog.


An option to auto-import whenever possible (without needing to move the cursor over the unknown element and press ctrl-shift-M) would be the next step and make things much smoother.

Comment 6 Eclipse Genie

2020-01-13 02:21:11 EST

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.