IDE refactoring support in Lombok project

Question

The Lombok project temptingly reduces the template code in our Java 8 code base. The disadvantage is that it limits tool support (refactoring, static analysis).

For example, in my experiments with IntelliJ, class field refactoring annotated by @Builder no longer works. I don't know the workaround (you need to manually fix the locations where the old name of the Builder method is used).

Another example is that in Eclipse “find links” in the field no links were found, but a good workaround is to open the path and apply the “link lookup” to the generated getter / setter.

My questions:

• What refactoring functions of the main IDEs (especially Eclipse, IntelliJ) break?
• Are there any good workarounds?

Answer 1

Below is a small workaround for refactoring a getter / setter variable in the @Data class. This works in an eclipse and possibly elsewhere:

An example of a class where we want to rearrange "value" to "value2":

 import lombok.Data; @Data public class Thing { int value; } 

(1) Rename (do not refactor) this variable to a temporary location to delete the created lombak getter / setter for the original name. You will get compilation errors wherever the old getter / setter was specified, but this is temporary:

 @Data public class Thing { int valueXXX; // reference to getValue() are broken for the moment } 

(2) Manually create a dummy getter / setter for the old name. Now your compilation errors will disappear:

 @Data public class Thing { int valueXXX; public int getValue() { return 0; } public void setValue(int value) {} } 

(3) Use eclipse to refactor your dummy getter / setter. All links in your codebase now use getValue2 () and setValue2 ():

 @Data public class Thing { int valueXXX; // public int getValue2() { return 0; } public void setValue2(int value) {} } 

(4) Remove the renamed dummy getter / setter and change the variable name from your temporary name to a new one. Now everything breaks down again:

 @Data public class Thing { int value2; } 

Admittedly, this is a little annoying, but it's not really that long, and he is confident that he will manage to change hundreds of links manually.

Answer 2

One I recently ran into:

In IntelliJ (I don't know about Eclipse) you cannot extract an interface containing any methods created by lombok. They do not appear in the corresponding dialog box.

There is a simple way: let IntelliJ create methods, retrieve the interface, return your class, and implement the interface again.

Answer 3

For more complex refactoring, I settled on "delombock-refactor-relombock". This is a tough approach, but it has advantages in handling complex refactoring without intermediate broken assemblies.

In my case, I use maven to build. I added the maven build plugin for lombok: delombok , configured as follows:

 <build> <plugins> <plugin> <groupId>org.projectlombok</groupId> <artifactId>lombok-maven-plugin</artifactId> <version>1.18.6.0</version> <configuration> <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory> <addOutputDirectory>>false</addOutputDirectory> </configuration> <executions> <execution> <phase>generate-sources</phase> <goals> <goal>delombok</goal> </goals> </execution> </executions> </plugin> </plugins> </build> 

This makes delombok copies easily available in the destination directory.

To refactor a specific class of clogs:

1. Comment out the original content of the class.
2. Replace with delombok class contents from target / generate-sources / delombok
3. Save (code compiles cleanly)
4. Refactor your IDE (code compiles correctly)
5. Do the same refactoring for the commented out original content of the lombok class
6. Delete contents of the class delomok
7. Uncomment the processed lombok class content
8. Save (code compiles cleanly)

I would expect skepticism for those who are looking at this for their first attempt to reorganize the lombok class. I arrived here only after disappointments and limitations by other methods and more complex lombok functions (i.e. @Builder, @SuperBuilder).

For example, manually adding the installation method for @Builder requires the correct declaration of the corresponding internal constructor generated by the lombok class. This is getting harder and harder to do with features like lombok @SuperBuilder builder inheritance. When I tried to do this manually, I decided to refer to the delombok class as a guide. It was then that I realized that it is easier to replace the delombok source, refactor as desired, and then delete it.