Bug 72024 UndoManager creates potential memory leak [refactoring]
3.0 The refactoring undo manager doesn't call dispose in all cases where a undo/redo object is no longer needed. This can result in a memory leak since the undo/redo object could register for listeners and therefore relies on the fact the dispose is called correctly. Cases where dispose isn't called: - if the undo stack reaches it maximum number of change objects and the last one is removed from the stack. - if the undo/redo stack gests flushed and one of the change objects causes an exception during sending dispose. - if the undo/redo object isn't valid anymore and can therefore not be executed.
org.eclipse.ltk.ui.refactoring/src/org/eclipse/ltk/ui/refactoring/RefactoringWizard.java
return internalCheckCondition(CheckConditionsOperation.FINAL_CONDITIONS);
	}
	
	private RefactoringStatus internalCheckCondition(int style) {
		
		CheckConditionsOperation op= new CheckConditionsOperation(fRefactoring, style); 
		Exception exception= null;
		try {
			PlatformUI.getWorkbench().getProgressService().busyCursorWhile(
				new WorkbenchRunnableAdapter(op, ResourcesPlugin.getWorkspace().getRoot()));
		} catch (InterruptedException e) {
			exception= e;
		} catch (InvocationTargetException e) {
			exception= e;
		}
		RefactoringStatus status= null;
		if (exception != null) {
			RefactoringUIPlugin.log(exception);
			status= new RefactoringStatus();
			status.addFatalError(RefactoringUIMessages.getString("RefactoringWizard.internal_error_1")); 
		} else {
			status= op.getStatus();
		}
		setConditionCheckingStatus(status, style);
		return status;	
	}
	
	private void setConditionCheckingStatus(RefactoringStatus status, int style) {
		if ((style & CheckConditionsOperation.ALL_CONDITIONS) == CheckConditionsOperation.ALL_CONDITIONS)
			setConditionCheckingStatus(status);