FEATURE IDEA: Lombok Refactoring

A tool (that would need an interface, and thus might be most useful as an IDE plugin) that can scan existing java source code and suggest ways in which lombok can remove boilerplate. For some transformations, this is straightforward (such as @Getter), but for others, this will need some user feedback (for example, the odds that a user’s hashCode() is exactly equal to what @Data generates is small, but nevertheless, a class with toString, hashCode, equals, that all look roughly look they are just boilerplate should trigger a suggestion to replace them all with @Data – it cannot make this decision automatically, however).

A basic design would probably involve a list of lombok transformations on one side, with checkboxes for each of them, as well as a list of files with candidate rewrites, which adjusts to only those rewrites with a selected transformation on the left hand side (so each transformation has a checkbox but can also be selected). Upon clicking a source file, a diff view is shown about what lombok suggests. The suggested version should be editable, and the page should have a save button, or a ‘leave as is’ button (which removes that file from the list).

A related idea: The IDE outline view can be a bit cluttered with all those boilerplatey getters and setters and such. A lombok plugin can mark them as generated somehow, for example by greying them out (the aim is to both make them less noticable in the outline view, AND to convey the notion that they are generated). The method itself does need to be in that list, as this is the only to refer to it, for example for purposes of ‘find callers’. Usually you can run ‘find callers’ on the annotation, but for annotations that generate multiple methods, this isn’t an option.