Skip to content

Instantly share code, notes, and snippets.

@dkandalov

dkandalov/what-is-wrong-with-IJ-refactoring-API.md

Last active October 27, 2016 23:40
Show Gist options
  • Save dkandalov/f9eb4af832f1b4d7a6c15351412d97ff to your computer and use it in GitHub Desktop.
Save dkandalov/f9eb4af832f1b4d7a6c15351412d97ff to your computer and use it in GitHub Desktop.
Download ZIP
Raw
what-is-wrong-with-IJ-refactoring-API.md

What is wrong with IntelliJ refactoring API?

  1. Classes implementing Refactoring interface can potentially display UI dialogs and wait for user input. This is part of Refactoring interface API (see isPreviewUsages method javadoc) and, therefore, affects other classes which use implementations of Refactoring interface, e.g. JavaRefactoringFactory.

For examples of code which displays dialog during refactoring, see BaseRefactoringProcessor.doRun implementation. I have not analyzed in how many places UI dialogs or user input might be triggered though.

Possible workarounds:

  • modify Refactoring interface so that user response can be implemented in code.
  • enable headless mode while executing refactoring so that UI dialogs are not displayed. This is a hack and invoking code will not be able to know if something went wrong during refactoring.
  1. Classes implementing Refactoring interface execute code modifications as undoable command (e.g. see BaseRefactoringProcessor.execute method). This is convenient for running single refactoring but for composite refactoring undo list will include all refactorings it consists of.

Ideally, code invoking Refactoring should be able to run it's own undoable command.

See youtrack issue https://youtrack.jetbrains.com/issue/IDEA-158086

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment