| Summary: | [add import] Automatically adding import can be unsafe | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Venkatesh Prasad Ranganath <rvprasad> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
Moving to JDT UI. 'add import' is not a refactoring but trusts that the user knows what he's doing. But you're right, for static imports this is trickier and we could warn. 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. |
Consider the following snippet class A { IWorkbench getWorkbench() { return PlatformUI.getWorkbench(); } } Since PlatformUI.getWorkbench() is static, pressing Ctrl+Shift+M to add a static import for this method will result in the following snippet import static org.eclipse.ui.PlatformUI.getWorkbench; class A { IWorkbench getWorkbench() { return getWorkbench(); } } Although the resulting code is syntactically correct, it is semantically incorrect -- the result leads to an infinite loop that did not exist in the original snippet. Hence, when the user invokes "add import" refactoring, the refactoring should check if the method/field referred to in the resulting expression is the same as the one being imported, i.e. check if the defining class of the refered method/field does not change. If it will change, then the refactoring should flag an error and abort.