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

Bug 297092

Summary: [reorg] Refactoring: Textual move members does not allow compilation unit as target
Product: [Eclipse Project] JDT Reporter: alexandra <astehman>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: markus.kell.r, Olivier_Thomann
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description alexandra CLA 2009-12-07 11:57:44 EST 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 20090920-1017

I have several attributes + accessors I'd like to move wholesale to another (nonfinal) class within the same package.  Regardless of whether I select one or all of the desired attributes to move, when I highlight the attribute(s) (regardless of whether in the source file or in package expl), select Refactor->Move, then select a (nonfinal, writeable) class in the SAME PACKAGE, Eclipse reports "the selected element cannot be the destination for this operation" (ReorgPolicyFactory_doesnotexist0).

I never had problems refactoring the locations of attributes between classes before (and there is absolutely nothing special about these two).

I did try DnD of the attributes from the source class in Package Expl to the desired dest class in the Proj Expl, and that moved the attribute decls (but not their associated accessor methods, which in large part defeats the purpose of refactoring).


Reproducible: Always

Steps to Reproduce:
1. Open up a project with a bunch of classes 
2. Pick a class that has attributes w/accessors
3. Try highlighting the attributes in Package Expl and attempt to refactor->move to a nonfinal class.
4. Try highlighting one of the attributes in the source file and attempt the same refactoring.
Comment 1 Olivier Thomann CLA 2009-12-07 15:08:41 EST 
Could you please provide an example?
Comment 2 alexandra CLA 2009-12-08 08:15:10 EST 
(Thanks to Walter Harley for detailing!)

1. create a new Java project;
2. add a new package p and new classes p.A and p.B;
3. add a public String x1 to p.A;
4. highlight x1 and select Refactor -> Move.

When I click B.java, I see an error message saying "The selected element cannot
be the destination for this operation."

However, if I expand the B.java item, under it I see sub-items for the package p
and for the class B. If I select the *class* B, I am able to refactor successfully.

Note that B.java can contain multiple top-level declarations, including multiple
class declarations (though only one of them can be "class B"). So in a sense,
what it's saying is true; you can't move a field into the top level of a .java
file, that is, outside the scope of a class.

But in the 95% likely case, where the .java file contains only a single
top-level class, the intent is very clear and I think this is a usability bug.
I didn't see anything about it in Bugzilla, so you might want to enter a
Bugzilla feature request.
Comment 3 Olivier Thomann CLA 2009-12-10 09:18:23 EST 
Moving to JDT/UI
Comment 4 Markus Keller CLA 2009-12-10 14:16:27 EST 
As the dialog title says, this is just a textual move, so no references are being updated in this case -- it just does a copy/paste of the source text.

There is no real refactoring for moving instance fields, and it would be very hard to write one that is behavior-preserving.

We could allow a compilation unit as target, though.
Comment 5 alexandra CLA 2009-12-10 14:53:08 EST 
>We could allow a compilation unit as target, though.

That would be useful, thank you.
Comment 6 Markus Keller CLA 2010-01-28 10:25:17 EST 
The fix for bug 297752 also fixes this.

*** This bug has been marked as a duplicate of bug 297752 ***