Community
Participate
Working Groups
EG (6/6/2001 6:54:41 AM) it is not critical for June. But we shouldn't automatically save the resource. This is inconsistent with organize imports. NOTES: DB (08.08.2001 17:01:05) I would like to defer this until we know how we will implement the new Code Manipulation Infrastructure. See also 1GEJ61L: ITPJUI:WIN2000 - Refactoring: operation aren't cancelable since the can't be executed in a different thread.
This is only possible if we get a better undo story. Currently we can only push undo commands on the refactorings undo stack if a file is save. Otherwise the next save would flush the current undo stack which would remove the undo object for extract method.
We cannot assume that we get a better undo story now, so we have to investigate alternatives. The problem is serious, when working with auto build this triggers a build. After an extract method is almost always an inappropriate time for a build. Why can't we implement a custom undo that works on a buffer.
This isn't so easy since the editor and the refactoring undo stack have nothing to do with each other. What can happen in this scenario that someone does an extract method, refactoring pushes and undo object onto the stack and we doen't save the file. Now the user starts editing and edits some text inserted by extract method. What do we do in this situation: - remove extract method undo from the stack again. - leaf it on the stack and hope that the user executes undo in the right order (first the editor undo and than the extract method undo). It is still my opinion that refactoring isn't the right place to deal with this.
Agreed, trying to synch to undo stacks is not doable. Suggest to remove Refactoring undo for Extract Method when auto-build is on. This is still a hack. There is a need to investigate into a better solution.
Still not possible since we still have the same undo problems. Still waiting for the final Undo proposal from workbench.
Problem still in I20020226 - leaving BR as is.
Erich, any objection if I mark this one as later. We still don't have a better undo stroy yet and I doubt that something will happen for 2.0
No action planned for 2.0
This is still an issue and we should find a solution for 2.x. Given the fact that we think about adding snap shoting support we could do the following: - all refactoring that manipulate a single file will use the editor's undo stack. This doesn't force refactoring to save the resource. - for refactorings manipulating more than one resource we use the "upcoming" snap shoting support.
Also exists in Eclipse 3.0M7 (build id: 200402122000) on Solaris 9 and HP-UX 11i platforms.
This was an intermediate problem that got fixed again for I20040309.
With Eclipse 3.0M8 (build id: 200403261517) on Solaris 9 and HP-UX11.11 platform, the problem still exist. The following is my procedure to reproduce the problem: 1. Download the 3.0M8 SWT Examples zip file from the eclipse.org site and load it on to Eclipse workbench. 2. Create a Java project and call it "JUnit". 3. In the Packages Explorer view, select JUnit project and from its context menu "Import->Zip file". 4. Browse to junit37src.jar file in <eclipse>/plugins/org.eclipse.jdt.ui.examples.projects/archive/junit/ directory. Select file name and click "Ok". 5. Click the "Select All" button to make sure that all the files are selected in the folder. Ensure that the destination folder is "JUnit". Click "Finish" and click "Yes" on the question box concerning .classpath file. 6. In the Package Explorer view, expand the junit.framework package, and select the "TestSuite.java" (double click to open the file). 7. Using Window > Preferences > Java > Editor from Workbench menu select "Show line numbers" from editor "Appearance" page. 8. In the TestSuite.java file, select the following range of code from Class superClass = theClass; to the end of "while" control statement (Lines 61- 69. 9. From the selection's context menu in the Editor window, select Refactor > Extract Method. 10. Enter Method name to be "collectInheritedTests" and click "OK". TestSuite.java is modified to contain the new method, in place of the original lines 61-69, is a method call to 'collectInheritedTests()' with parameters for the variables used in the extracted code. The new method 'collectInheritedTests ()' appears in the Java code (and Outline / Package Explorer views). 11. Close the TestSuite.java Editor window. No prompt dialog is displayed mentioning that the file has been modified, with a prompt to save the file. The TestSuite.java file is saved automatically! This may not be the desired functionality on the part of the software designer. Please reopen this bug report. Thanks.
Do you have autobuild on ?
Yes. I did have "Perform build autmatically on resource modification" selected. Does that mean I have to turn it off before refactoring for no autosave? Eclipse will not autosave if I just edit the file. It will provide me with errors only. After everything is fine it still will not autosave the file. May be a warning forRefactoring on autosave is needed?
I agree with Brian So’s comments. Enabling “Auto Build” option should not force Eclipse to automatically save the associated class file. Extracting Java code into a method will not save the associated class file if it is done manually. Therefore, the automated option must behave the same way in order to ensure the consistency. I think this defect should be reopened.
Here is how this is currently implemented: if the file is dirty then it is left dirty. If it is saved, it is saved afterwards.
I think this behavior of Eclipse is confusing. I would save a file before I modify its original content (in this case moving a part of its source code into a method) if I want to preserve the earlier work. If Eclipse automatically saves the file immediately after refactoring is done, then the previous work would be destroyed. So, what is the point of saving the file after all? I believe that this behavior of Eclipse should be changed.
