Lombok getter/setter vs Java 14 record

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:

1. it has even less ceremony than a class annotated with Lombok
2. it carries the semantic information "this is an immutable data class" (as emphasized in Brian Goetz's answer). This semantic information may be valuable both to programmers and to frameworks.

I would still use Lombok if your class cannot live with the restrictions of records (e.g. immutability, no builder, not extensible).

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.

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.)

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:

Lombok

• Records are not yet as powerful a tool to eliminate Lombok all together. Note that the library has much more to offer than just the @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
• Experienced by self, the EqualsAndHashCode is not the same as you would expect when it comes to migrating to records.

Records

• Records are an official part of the language, with support of all major IDEs
• On a different note, if the requirement of your object representation is to be a "data carrier" you can still seek advantage of Records, without relying on an additional library to reduce the boilerplate code to perform that precisely. That is the reason that as a conclusive note this blog reads the following:

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.