Java 14 Records :: did we live to see getters and setters die?

Is it the end of the line for getters, setters, and Lombok project?

Photo by Mike Kenneally on Unsplash

If you try to teach Java to someone coming from another less verbose language, you can often face resistance regarding the writing of getters, setters, toString, equals, and hashCode methods and the need of so much boilerplate code.

Vintage developers will not bother about it. We simply got used to instructing the IDE to generate them for us.

But let’s face it: we don’t particularly like them. We just got used to them. We accepted the need for these methods, but to be honest: it could be different.

Java 14 has launched records: a preview feature for a new type that dismisses the necessity of getters, setters, toString, equals and hashCode methods. It is possible to create an object with a few lines of code.

Since it is yet a preview feature, we should enable preview features on our compiler, IDE and/or Maven.

In summary records have the following characteristics:

  • They are final and immutable.
  • They can implement interfaces.
  • They can have static members.
  • They can define validations.
  • They can define default values.
  • They accept generics.

I have tested it and the project is available on my GitHub.

All passed! \o/

Observe that records do not have the classic getters and setters and therefore, it is impossible to modify their values once they are assigned.

Note on the lines 34 to 38 below that the reading of attributes, is done without the “get” prefix. We use the attribute’s name straight forward.

Records are compatible with our classic interfaces. Check the record “SpecialDate” that implements the interface “CelebrationInterface” and therefore overwrites the method “totalDates()”. Observe lines 13 and 48 on the following example.

For an extra static member check line 18.

For a validation check line 28.

For a default value, check the alternative constructor on line 41, which assigns the current date and time for the created object, even if it is not informed during the record’s object creation.

Records are flexible and accept generics! The definition can be found below and the example on how to use it is available on the test “celebrationGenericRecord_ok()” of class “RecordsDemoTest”.

Short answer: to carry data.

Less short answer: now we can declare a simple data transfer object with a few lines of code and without the need to satisfy all the ceremonies that we are used to having in Java, meaning CLEAN code!

Since records are compatible with other Java’s important features, I am really excited to start to use this. It gives me so much satisfaction to remove extra code on my projects. 🙃

Well then… is it the end of the line for our beloved-hateful pet methods getters and setters? Hmmm… Apparently not quite yet.

Since records are immutable they cannot simply replace our classic classes. Also, another concern to be addressed is how compatible are they with frameworks as Hibernate or Spring? I did not figure it out until the present moment.

They will, however, help us to make code cleaner and smaller and in some cases, they could even eliminate the need of external libraries such as Lombok, as stated Ben Evans for Java Magazine:

“This will help many applications make domain classes clearer and smaller. It will also help teams eliminate many hand-coded implementations of the underlying pattern and reduce or remove the need for libraries like Lombok.”

It is important to keep in mind though, that this is a preview feature and as the documentation reminds:

“Preview features may be removed in a future release, or upgraded to permanent features of the Java language.”

I hope they keep it. Fingers crossed.

Software Engineer. Always learning.