Bugzilla – Full Text Bug Listing
| Summary: | "move static members" refactoring should be able to create new class on the fly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Patrick Julian <mail.recycling> | ||||
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | mail.recycling | ||||
| Version: | 4.3 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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.