Community
Participate
Working Groups
This is a fix candidate for 1.0 Changing the name of the top-level type of a CU followed by save prompts the user whether they want to rename the compilation unit as well. The current implementation is problematic since the prompt is done inside the delta processing. As a consequence, when changing a type programmatically a dialog can show up as a side effect. We have removed this behaviour in the 2.0 stream since the same effect can be achieved with the rename type refactoring. Proposal is to remove this behaviour in the 1.0 stream as well (1.0 already has the rename type refactoring).
This would be the fix The fix is even simpler: In CompilationUnitEditor's default constructor: /** * Default constructor. */ public CompilationUnitEditor() { super(); setDocumentProvider(JavaPlugin.getDefault ().getCompilationUnitDocumentProvider()); setEditorContextMenuId("#CompilationUnitEditorContext"); //$NON- NLS-1$ setRulerContextMenuId("#CompilationUnitRulerContext"); //$NON- NLS-1$ setOutlinerContextMenuId("#CompilationUnitOutlinerContext"); // $NON-NLS-1$ fSavePolicy= new CUSavePolicy(); } set the fSavePolicy to null.
fixed in 1.0 stream
One case to consider (for 2.0 not the 1.0 rollup) is 1) Edit a .java file to change the class name, save (you get problems) 2) Select the class in its outline and rename back to the old name You are not able to do this since it detects that the file exists, but since it is the file you are changing, this case should not fail.
fixed in rollup1