I love project Lombok but in these days I'm reading and trying some of the new features of java 14.
Inside the new capability, there is the record keyword that allows creating a class with already built-in the following functionality: constructor, private final fields, accessors, equals/hashCode, getters, toString methods.
Now my question is: is better to rely on the feature of Lombok or should we start using the record functionality:
Is better to use this:
record Person (String name, String surname) {}
or that:
@AllArgsConstructor
@ToString
@EqualsAndHashCode
public class Person {
@Getter private int name;
@Getter private int surname;
}
What are the pros and cons of the both approach?
NB: Instead of that christmas tree of annotations, you can just use @Value on the class. Note that this makes the class final, and makes all fields both private and final, and gives you all the rest as well. This is close to what records are (they too are final, and all fields inside are final).
record is still in preview, so for production code, obviously it's not, yet, suitable. Use lombok.
Once records are out of preview, it's more complicated. Lombok is FAR more flexible; you can easily swap in some new aspect without having to rewrite all the code (you can just, for example, add an 'extends' clause to your class without having to then handwrite the equals and hashCode method; something records cannot give you). Lombok also gives you more features: You can for example add a builder by adding the @Builder annotation; not something records can do.
If it's highly unlikely you're going to use any of that for the class you're designing - I'd use records.
DISCLAIMER: I'm a core contributor to Project Lombok.
I've been playing around with this combination for some time as well and with the slight bit of hands-on I could list down the following differences:
@Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.EqualsAndHashCode is not the same as you would expect when it comes to migrating to records.It will also help teams eliminate many hand-coded implementations of the underlying pattern and reduce or remove the need for libraries like Lombok.
Of course, on a day-to-day basis, it is always wise based on the requirements of a project to choose which way to follow and practice.
Lombok, and the record feature of the Java language, are different tools for different things. There is some superficial overlap, but don't let that distract you.
Lombok is largely about syntactic convenience; it is a macro-processor pre-loaded with some known useful patterns of code. It doesn't confer any semantics; it just automates the patterns, according to some knobs you set in the code with annotations. Lombok is purely about the convenience of implementing data-carrying classes.
Records are a semantic feature; they are nominal tuples. By making a semantic declaration that Point is a tuple of (int x, int y), the compiler can derive its representation, as well as construction, declaration, equality, hashing, and string representation protocols, from this state description. Because they carry semantics, readers and frameworks can also reason with higher confidence about the API of records. (This may also be syntactically convenient; if so, that's great.)
Java Records don't require any additional dependency, so it's better to use them instead of Lombok I think.
If your project supports Java 14 you can already use them in Eclipse.
There's a plugin in the marketplace for it:
https://marketplace.eclipse.org/content/java-14-support-eclipse-2020-03-415
While Brian explains well the different goals of Lombok and records, he does not explain when to use which.
If your class is a "transparent, shallowly immutable data aggregate" then a record will do a great job because:
I would still use Lombok if your class cannot live with the restrictions of records (e.g. immutability, no builder, not extensible).
In short, if you are doing functional coding with Java, use records. Otherwise use Lombok, it is much more flexible and powerful.
There are some exceptions to this rule for e.g. in API coding.