Lombok, or annotation driven development - profits and risks

When writing code in java and creating new classes, we often need to write methods that are practically almost the same for different classes. For example, having:

1public class User {
2private String username;
3private String email;
4}

That is, a simple small class holding user data, we will probably need to create:

• constructors (default and with parameters)
• getters and setters
• equals and hashcode
• toString

So, our little class grows from a few lines to as many as 60 (for the sake of readability of the article, I will omit the IDE-generated code). Despite the sprawl, we didn't add any business logic. It didn't add anything. Such code is called boilerplate code - that is, code that doesn't contribute anything to us, but is needed to be written to make the application work.

Lombok

With our help comes the lombok library, which generates this boilerplate code based on the annotations used. To start using lombok, we add its dependency:

1<dependency>
2<groupId>org.projectlombok</groupId>
3<artifactId>lombok</artifactId>
4</dependency>

If we are not using Spring Boot, we will also need to add a version. We can now write the equivalent of a 60-line class with the help of some self-explanatory annotations:

1@AllArgsConstructor
2@NoArgsConstructor
3@Getter
4@Setter
5@EqualsAndHashCode
6@ToString
7public class User {
8private String username;
9private String email;
10}

As you can see, we saved many lines of code. We went in the direction of declarative programming - we say what we want to have done (using annotations), not how it should be done.

However, annotations have arrived - we can even use a "certain set" of annotations, such as the following example:

1@AllArgsConstructor
2@NoArgsConstructor
3@Data
4public class User {
5private String username;
6private String email;
7}

@Data includes @Getter, @Setter, @RequiredArgsConstructor, @ToString and @EqualsAndHashCode.

Also useful is @Builder - with this, we will have a builder pattern provided when creating objects of a class.

Lombok - disadvantages

Okay, we don't have boilerplate code - so are there any disadvantages?

The first one you'll think of is the lack of debugging capabilities - you won't put a breakpoint on the annotation and you won't see the method parameters. Okay - you can perform the process of so-called delombok, and put a breakpoint in the generated code, but then all the fun starts to lose its meaning. Having a collection of annotations(colloquially, pejoratively, this can be called annotation driven development) it is easy to get lost in this thicket - for example, having a class labeled like this:

1@Data
2@Value
3public class User {
4private final String username;
5private final String email;
6}

We don't immediately see which methods are generated and which are not. Only later do we find out that @Value contains @AllArgsConstructor, @Data contains @RequiredArgsConstructor, while in all of this we are missing... @NoArgsConstructor, the default constructor. What could be the effect of this? Some serialization/deserialization libraries, such as Jackson, require a default constructor - otherwise, an annotation should be applied to the constructor with parameters. Unfortunately, this will come out only in the runtime....

Summary

As you can see, the use of lombok allows you to significantly reduce boilerplate code and thus speed up the software development process and increase the readability of the code. However, do not forget to use common sense, so that one day you do not find yourself in a thicket of annotations alone, because in the event of any error, tracking down the cause is much more difficult.