Java developers, particularly those coming from other programming languages, have long complained about the overwhelming amount of boilerplate code found in Java codebases. In Object-Oriented Java development, the necessity of ensuring encapsulation and immutability of objects only adds to the amount of boilerplate code required. This issue is a common pain point for developers and can be exemplified by tens or even hundreds of lines of getter and setter methods per source file, as well as extensive class constructors. In response to this problem, Project Lombok was created.
Lombok
Project Lombok is a java library that automatically plugs into your editor and building tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, automates your logging variables, and much more. (from https://projectlombok.org/)
Basically, Lombok uses meta-programming to generate code at compile time. In addition to the possibility of generating getters/setters methods, it can generate equals methods, hash code and a variety of class constructors. Besides the possibility of generating class-level attributes, for instance, a logger attribute using LOG4J. It may seem mysterious, but in fact, Lombok uses two native Java features to generate this code. Let's explore these features below.
How does Lombok work?
Annotations
Annotations were introduced in Java a long time ago, in version 6. And Lombok has a series of annotations that can be used to identify/mark the need to generate new code within that class.
AST (Abstract Syntax Tree)
Abstract Syntax Tree is the way the compiler represents the steps that need to be performed for the final program to be generated. AST Java is a kind of intermediate structure that is created before the byte code is generated. Java has its own AST and it can be manipulated.
Image source [https://sewiki.iai.uni-bonn.de/_media/research/jtransformer/lmp.jpg]
So, if we join these two technologies/features everything starts to make sense. During the compilation phase, Lombok annotations are identified and Lombok manipulates AST to insert code that did not exist before into existing classes.
However, Lombok doesn't do this in a snap. It needs to intercept calls to the Java compiler in order to handle the intermediate code that will be generated. This is done through plugins, either in your IDE (IntelliJ, VSCode, Eclipse) or via building tools (Maven/Gradle/Make). If your IDE or your dependency/build manager does not support Lombok your code will not compile.
Considerations
Compilation time
Due to Lombok performing its magic at compilation time, you can expect an increase in the compilation time of your Java project/codebase. And this increase can have a high impact, especially on large codebases, the more code to generate the more AST to handle. The Lombok development team has been working to lessen this impact and has succeeded, but the time is still longer with Lombok than without it.
Java Standards
Let's say you're trying to compile your source code using only javac (the java compiler) and the source code uses a get method generated by Lombok in this case you will get a compilation error saying that the get method doesn't exist.
It happens because a source code that uses Lombok annotations is not a valid Java source code. (Controversial but sincere)
Is this a problem? The answer is yes and no. Yes, because you will always depend on Lombok plugins for your source code compilation to work. No, because in most cases developers use IDEs or building tools to compile their Java code.
Compatibility
Another point of attention is the compatibility with future and previous versions of Java. With each version, Java may change the way AST is generated and interpreted. In version 8 it can be one way and in version 9 another way. So Project Lombok needs to update its dependency library to generate the code in the most up-to-date way, and of course, maintain backward compatibility as well.
If you are using Lombok, it is possible that your project will fail to compile if you upgrade your Java release.
It's a problem? Yes and no. Yes, because you will only notice that your code stopped compiling after you perform the Java upgrade. No, because Project Lombok usually releases library updates before the final versions of Java. But remember, if you use Lombok be aware of possible future compilation failures for the reason I've described above.
Boilerplate code
This is where Lombok gains popularity, in the emotional and most visible part of the source code. No doubt Lombok drastically reduces the amount of boilerplate code in your Java classes, especially in domain classes (TOs, DTOs, Entities) where usually we have a lot of class-level attributes.
If we count 3 lines of code for each get method and 3 more lines of code for each set method we will end up having a reason of 6 lines less for each class attribute if you are using Lombok to generate get and set for all of the class attributes. In a class with 10 attributes, you will save 60 lines of code minus the lines containing Lombok annotations. Besides equals, hash code, toString and other methods.
That is good? Yes and no. Yes, because your source code file will be smaller, simpler, and for instance, if you add a new attribute the boilerplate code related to that attribute will be generated automatically. No, because all IDEs, from the simplest to the most complete, can generate this boilerplate code with one or two clicks.
Concluding
Lombok has its advantages, but it also has its drawbacks. A major issue in my opinion is that it can make your code less readable, especially for developers who are not familiar with Lombok's annotations. This is because the annotations can hide what the code is doing, and may make it more difficult for other developers to understand what is happening behind the scenes.
Another potential drawback is that Lombok is not supported by all IDEs out of the box, which can make it more difficult to set up and use. And Lombok doesn't always play nicely with other libraries or frameworks, which can cause compatibility issues and make debugging tricky and longer.
Despite these, Lombok can be a powerful tool for simplifying your code and reducing boilerplate. It's up to you to weigh the pros and cons and decide whether or not it's worth using this library in your project. Ultimately, whether or not to use Lombok comes down to a matter of personal preference and what works best for your team and your project.
Personally
In my personal experience, I tend to avoid using Lombok in my projects. When discussing this topic with my team, I share the points mentioned in this post, and we make a decision based on the project requirements and context. In some Java teams, we've used Lombok, and in others, we haven't, without any negative impact on the project. One noteworthy project I worked on in recent years did not use Lombok, yet it was still very successful. The decision to use Lombok or not depends on a variety of factors and should be evaluated on a case-by-case basis.
The clear advantage is having less code to maintain. However, this type of code (boilerplate) is not considered critical and can be easily generated by your favourite IDE. And the drawback is adding more complexity to your codebase, especially on the project building time and compatibility with future Java versions.
Some of the use cases for using Lombok can be tackled by using Java Records, check my other article.
Lombok will not determine the success or failure of your project. But if you need to decrease the size of your Java classes Lombok can be helpful. But don't forget to take into account the points that were listed here.
Top comments (4)
Congrats!!! Awesome article!!! I agree with you about the Lombok usage... Lombok can add more complexity to your code and it can requires some cognitive load from the team that maybe, it does not brings valuable in long term. Again, congrats!!!
This article will help developers make an informed decision whether to use Lombok or not.
Keep up the good work, you are doing well!
Yup, have the same mixed feelings. I like the idea of only seeing code that has some behavioural value but don't at all like the dependency (added to the fact that in some IDEs, VSCODE notably, you cannot see what lombok has actually generated).
Got your point but besides your opinion, what are the references and supportive studies?