Bug 437129 - "move static members" refactoring should be able to create new class on the fly
Summary: "move static members" refactoring should be able to create new class on the fly
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-11 09:06 EDT by Patrick Julian CLA
Modified: 2014-06-13 10:13 EDT (History)
1 user (show)

See Also:

Attachments
Current behaviour (34.34 KB, image/png)
2014-06-11 09:06 EDT, Patrick Julian CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Julian CLA 2014-06-11 09:06:32 EDT 
Created attachment 244149 [details]
Current behaviour

Current behavior:

The refactoring tool "move static members" asks for a fully qualified type name.

If you want to move a constant to a new class, that is not possible.
An error appears. See attachment. Same error appears if you prefix it with the desired package.

Suggested behavior:

Moving the static member to a new class should be supported by eclipse as well.

Sure you can create the class by hand and then move the constant. But these steps may easily be joined into one.
The easier refactoring tools work, the likelier they are used.

You can infer in the attachment that
* if the source file type is .java, the target type will also be .java 
* if the source file namespace is com.example.something, the new artifact should also be created there, unless explicitly specified otherwise by the user

Eclipse could issue a warning note that the specified class has not been found and that it is going to create a new class based on the prescribed reasonable assumptions. If you want to be very sure, the IDE can have the user confirm that the assumption is right.