Records and Lombok as JDBC Entity

Posted on
Records and Lombok are useful, when they are used wisely

As a Java Developer we’re today very familiar with records(right?).
It isn’t uncommon we’ve Lombok on project as well.
These are good tools, when they are used wisely.
At the moment we put them together as JDBC Entities, so, here strange things begin.

Let’s say we want to represent a Car.
Having manufacturer, model, color and year, just KISS.
A scenario where you’re using Spring Data JDBC.

The most common is doing something like:

1
2
3
4
5
6
7
8
9
10
11
@Table(name = "car")
class CarEntity {
  @NotNull
  String manufacturer;
  @NotNull
  String model;
  @NotNull
  String color;
  @NotNull
  Year year;
}

However, people obsessed by things like avoid boilerplate, I love Lombok, let’s make Java in a Functional way, immutability everywhere, etc.
The result, things like this beautiful code:

1
2
3
4
5
6
7
8
9
10
11
12
@Builder(toBuilder = true)
@Table(name = "car")
record CarEntity(
  @NotNull
  String manufacturer,
  @NotNull
  String model,
  @NotNull
  String color,
  @NotNull
  Year year
){}

Records + Builder as a nEntity.
You know, I don’t disagree 100%, at all.
The record can bring immutability on Spring JDBC stuffs, cool, fine.

My point is the mentality boilerplate is evil, so, go use annotation to hide them…
Looks like a harmless code, until we observe the details and see that below:

1st, we’ve an entity as record

The records idea is fill all fields at creation.
Using a Builder, they’re like enemies.
Record says: “You must pass all fields, mate”.
Builder says: “You’re free to just fill what you want, be free my friend”.

2nd, It’s not visible to us by @Builder does

It injects a static class Builder inside the Entity.
Builder brings a lot static methods plus an extra toBuilder method.

3rd, It makes us break the contract

On the example we have all fields required.
But, using builder() we start to break the contract by defining only some the fields, e.g:

1
2
3
4
CarEntity.builder()
  .manufacturer("Ferrari")
  .color("Red")
  .build();

What about the other ones required fields model and year?
Or even this one more bizarre:

1
CarEntity.builder().build();

Really? Class + Static Class + builder() + build()?
It doesn’t make any sense to our Domain.
Even all fields were not required, I still see that CarEntity.builder().build();
Where, in place, we should create a no args constructor in a fashion way: new CarEntity().
Period.

I’m not against records or Lombok.
I’m against bad pattern we bring to codebase when put all these things together. We need to use them wisely.

Thing about the Domain we’re creating, understand?
A good class design prevent us vulnerabilities for bugs.
Don’t be blinded about no boilerplate, function programming, immutability, records everywhere.
Use the language’s APIs as it’s designed to be used.

xoff.