The AutoRefactor project delivers free software that automatically refactor code bases.

The aim is to fix language/API usage in order to deliver smaller, more maintainable and more expressive code bases.

The first software will be an Eclipse plugin to automatically refactor Java code bases. License will be dual licensed under EPLv1.0 and GPLv3+.


After years working in different large code bases, I (Jean-Noël Rouvignac) got tired of spending too much time applying the same code cleanups again and again. In addition, tools like SonarQube™ (providing their own Java analyzer and also supporting the aggregation of FindBugs™, Checkstyle and PMD) are fantastic, but they do not not help fix the thousand warnings you can find in legacy code bases.

I decided I had spent too much time on manually doing these changes, so I tried using regular expressions. They work great for some code transforms, but can only do so much: they do not understand the language semantics, reapplying them again and again consumes time, they sometimes fail to execute due to too much complexity. I then sought for better and libre solutions, but found none. This is when I started AutoRefactor.

Software rots, particularly if the developers in charge do not care enough. Software has to be nurtured like a garden. Other causes for software rot are:



Look at the samples showcasing each refactorings available in AutoRefactor.
The samples are extracted from the unit tests suite.


There are several ways to use AutoRefactor: Alternatively, you can open a Java file, or select one or several files, packages or Java project, then right-click > AutoRefactor, then: You can see which changes have been applied in the "Git Perspective" (git) or the "Team Synchronizing" perspective (CVS, Subversion). You can also see which changes have been applied by looking at individual files Local history, and comparing the last revision with the previous revision.

Best practices

Developers are responsible for what they commit.

Since each commit should have a single purpose, it is recommended to separate code refactorings from features/bug fixes, and commit them separately from each other. See Martin Fowler's Preparatory refactoring from Workflows of Refactoring.

How to do mass refactorings?

The suggested approach is to run only one refactoring rule at a time to do single purpose commits. Once the refactoring rule has finished running, do a pre-commit code review to check all the changes are approved by the developer. Commit the change, then move on to run the next refactoring rule and start the same process until all rules have been applied and all the changes have been committed.
From now on, a developer can run the whole suite of refactorings without being overwhelmed by all the changes to review.


2017-09-29 - v1.1.0 is out!

Many refactoring rules based on pattern matching are part of the release. Give it a try!


From the Eclipse marketplace

Drag to your running Eclipse workspace to install AutoRefactor: Drag to your running Eclipse workspace to install AutoRefactor

From AutoRefactor update site

stable release
nightly (maybe unstable)

For more adventurous users, nightlies (potentially unstable) are available at "".


How to Contribute


Please support this project if it was useful to you. Consider the alternative: how much would it cost you to manually fix all the code?


Please contact me if you would like to sponsor a feature.



Developers corner

Easy hacks





Find here several books inspiring everyday how and why this plugin is written:
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Creative Commons Attribution-ShareAlike 3.0 logo This website is (C) 2013-2018 The AutoRefactor project and is licensed under the terms of the Creative Commons Attribution-ShareAlike 3.0