Lombok getter/setter vs Java 14 record

Question

I love project Lombok but 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 it better to rely on the feature of Lombok or should we start using the record functionality:

Is it 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 both approaches?

Glendaglenden

For one thing, record will not work for things expecting JavaBeans-style getters and setters. – Ghazi

What Rotteveel’s comment means is that the property accessor method on a record is named the same name of the property. So, alice.phoneNumber() rather than the JavaBeans convention of prefixing with get, as in alice.getPhoneNumber(). – Passional

Records have a lot of restrictions compared to classes, a record can't extend an other record or class for instance, check the restrictions section on this JEP openjdk.java.net/jeps/359 for further details – Seessel

Your sample is heavily biased toward record. When written without all the fat you added on the old class then the difference is much slimmer: record Person (String name, String surname) {} vs: @Value class Person { int name; int surname; } More other, just change @Value to @Data and magically you'll have a non-immutable class compatible with ORMs. Something that is not possible or difficult to achieve with java 17 record. – Nucleoprotein

Answer 1

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

Herefordshire

+1 Brian Goetz: And that's assuming the you can get the current Lombok version into your IDE. I wonder if Lombok has any meaningful advantage as regards quicker code reading that a class comment would not confer. – Twelvetone

I contend that they are not quite named tuples - general tuples don't require any definition. But record types still need to be defined ahead of usage. In C#, this can be done: (string first, string middle, string last) methodThatReturnsATuple() – Misteach

@Misteach If you get to define "tuple", then of course you are correct. We had this same debate about whether Java 8 lambdas were "real" closures; this always came down, at some level, to "I think 'closure' means X because that's what it meant in the first language in which I encountered it." But its not a very productive debate. – Herefordshire

There are numerous differences to what a sensible definition of a tuple would be so I think its a misleading to associate record types with tuples in anyway. For example: record Point(int x, int y) { } record Offset(int x, int y) { } var p1 = new Point(1, 2); var o1 = new Offset(1, 2); System.out.println(p1.equals(o1)); This prints out false, but this doesn't make sense for tuples.. – Misteach

I think that it might have been useful to include a disclaimer of the sort that rzwitserloot did before you, indicating that you were the author of Records (openjdk.java.net/jeps/384). You may be biased as to their flexibility and utility as compared to @Value. – Baroness

Answer 2

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.

Sajovich

@Builder support for records was added in v1.18.22 in October 2021 — github.com/projectlombok/lombok/issues/2356 – Conveyancer

Answer 3

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.

Allative

Note - I would try to keep this updated with more examples for being a user to use both of them frequently at present. – Allative

Answer 4

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

Isolated

Answer 5

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

Intraatomic

Lombok doesn't require any additional dependency on your built code either. Lombok and records both have advantages and disadvantages but an extra dependency is not one of the considerations you should look at. – Adeno

Answer 6

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.

Cynarra

Functional coding makes very little, if any difference to whether to use records or Lombok. – Adeno

Records are Java immutable data classes, there is nothing said about functional code in this scope. – Evolute