Many Java frameworks today require access to object values through standard methods of getter / setter. It does not require public fields through objects that we can access, but htoong through these default methods, so we have to control what data can enter and leave the object. Another good idea is to add, specifically, the model class toString (), hashCode () methods to use to compare instances of objects of the same class. The results of these suggestions appear in many lines of code even for simple classes. Just like when we need to update those classes, it will require rewriting our comparative methods, which consume our time and creativity. Fortunately, we have Project Lombok.
How it work?
Lombok is a relatively small project that uses specific annotations to be inserted into the source code. Compared to other similar solutions, Lombok does not use refection, but all these methods are generated automatically during the compilation process.
And that is all tenet.
Okay. What are the code samples here? In short, it is part of the source code which relates to what is added (for example by frameworks), but thus the source code will be really long, repetitive and boring at maintain. As well as getter / setter, equals, and others are crammed.
That’s right, so let’s look at some examples.
@Getter / @Setter
This first one is pretty obvious. By adding @Getter and @Setter annotations we don’t need to worry about these methods, which will definitely shorten your model classes.
1 2 3 4 5 6 7 8 9 10 11 12 13 | import lombok.Getter; import lombok.Setter; @Getter @Setter public class User { private String username; private String email; private String firstName; private String lastName; } |
@EqualAndHashCode
Another interesting addition to model classes is the equal () and hashCode () methods that are used to define independent instances of a class. By default all objects inherit from the Object class, but it is a great way to override them.
1 2 3 4 5 6 7 8 9 10 11 | import lombok.EqualsAndHashCode; @EqualsAndHashCode public class User { private String username; private String email; private String firstName; private String lastName; } |
@ToString
Another interesting annotation is the @ToString which overrides methods that return class description text. Typically it will be valid for all fields. Using Lombok we can generate it using a single annotation and it needs to remove some of them you need to provide an exclude parameter. Like the method parameters, we need to pass the name of the field.
1 2 3 4 5 6 7 8 9 10 11 | import lombok.ToString; @ToString(exclude="email") public class User { private String username; private String email; private String firstName; private String lastName; } |
@NoArgsConstructor
The final annotation that needs to be mentioned is used for the automatic generation of the class’s parameterless constructor. The default Java compiler will add it for you unless you have implemented any other constructor. For example, if you define a constructor that has some parameters, that means the compiler will not automatically add the constructor with no parameters for you. You need to do it in your source code. And that is why we can use this annotation.
1 2 3 4 5 6 7 8 9 10 11 | import lombok.NoArgsConstructor; @NoArgsConstructor public class User { private String username; private String email; private String firstName; private String lastName; } |
Other annotations
The annotations above that we also need to use for our project. But there are a few other great ones:
- @NonNull : This annotation eliminates the need to add methods that check if the field’s value is null or not.
- @Log : There are several variations when using it. Put simply, it creates a Logger object for us (Could be a Log4J2 variant).
- @Data : This annotation combines @Getter , @Setter , @ToString , @EqualAndHashCode and @RequiredArgsConstructor into one. The end result is we will have a constructor with all parameters being final fields.
Apply to the our project
Step 1: Install Project Lombok plugin
For IDEs built on Intellij’s platform we can easily install this plugin through the Marketplace. Or you can also find this plugin through the official website .
Step 2: Add dependencies
Add your build.gradle file:
1 2 | compileOnly 'org.projectlombok:lombok:1.16.20' |
Step 3: Annotate model class
After creating a few model classes that are marked with the necessary annotations. The example below is the User Class, which is set with standard methods (gettters / setters, equals, no argument constructor, but the toString () method should not show the password. must be a good idea if we reveal it).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | @Getter @Setter @EqualsAndHashCode @ToString(exclude="password") @NoArgsConstructor public class User { private int id; private String username; private String password; private String email; private boolean enable; private String firstName; private String lastName; private String phone; private Date birthday; private String address; private String postalCode; private String city; private Timestamp recordCreated; } |
Another use case
We can also use some Lombok annotations to bypass the calculation of coverage in Android apps using jacoco. The reason is because from Jacoco 0.8.0, this coverage tool can bypass the code generated from Lombok. This makes it possible for you to use @ lombok.Generated annotation to bypass some methods, or classes in the process of calculating coverage of jacoco quickly + conveniently.
You can refer to here .
Source
https://medium.com/@wkrzywiec/project-lombok-how-to-make-your-model-class-simple-ad71319c35d5
Reference
Ignoring Lombok Code in Jacoco .
How to write less and better code, or Project Lombok .
P / S
If my viblo posts have a Source , this is a translation from the source that is linked to the original post in this section. These are the articles I selected + searched + synthesized from Google in the process of dealing with issues when doing practical projects + useful and interesting for myself. => Translate as an article to rummage through when needed. So when reading the article, please note: