What are they?
On the surface, records seem to just be syntactic sugar for producing a class that can hold some specific combination of data. They can be used to make code less verbose, but there's more to them than that.
What do we get for free?
equals, hashCode, and toString methods are automatically implemented. If we need to deviate from the default behaviour of these methods then we can still specify the implementation in the same way that we would override those methods in a normal class.
What else is special?
Records are implicitly final, so you cannot extend from them with a sub-class. If you want to combine them with some other data then declare another Record that contains the original as a component.
That doesn't prevent us from including generics or annotations in the same way that we do with regular classes.
Why are they?
Records are a special type of class in Java that enables developers to represent their data with less of an extensible mindset, that aligns with "Favor composition over inheritence" from Joshua Bloch's Effective Java book.
JDK Enhancement Protocol (JEP) 395 goes into more detail about the motivation and history of introducing records as a feature of the JDK.
Considerations for use
Records have been a part of Java since version 16, with Java 17 as the first long term support (LTS) version top include them.
Java 17 was release in September of 2021, so at the time of writing this post we are at a point where we can expect any stable and mature libraries to be well and truly up to speed with operating with records.
One situation where records cannot be applied is as an @Entity in the Java persistence API (JPA).
Caveat
This post has mainly been created as a refresher / reminder to myself about where records fit in Java development. I applied them in an interview about three years ago, but was a little rusty on the pros and cons when it came to a similar interview more recently.
If you want to get deeper, go and check out the JEP or other documentation.
Comments
Post a Comment