83. Declaring a Java record
Before diving into Java records let’s think a little bit about how we commonly carry around data into a Java application. You’re right … we define simple classes containing the needed instance fields populated with our data via the constructors of these classes. We also expose some specific getters, and the popular equals(), hashCode(), and toString() methods. Further, we create instances of these classes that wrap our precious data and we pass them around to solve our tasks all over our application. For instance, the following class carries the data about melons like melons type and their weights:
public class Melon {
private final String type;
private final float weight;
public Melon(String type, float weight) {
this.type = type;
this.weight = weight;
}
public String getType() {
return type;
}
public float getWeight() {
return weight;
}
// hashCode(), equals(), and to String()
}
You should be pretty familiar with this kind of traditional Java class and this tedious ceremony, so there is no need to insist on this code. Now, let’s see how we can accomplish the exact same thing but using Java records syntactical sugar that drastically reduces the previous ceremony:
public record MelonRecord(String type, float weight) {}
Java records have been delivered as a feature preview starting with JDK 14, and it was released and closed in JDK 16 as JEP 395. This single line of code gives us the same behavior as the previous one, the Melon class. Behind the scene, the compiler provides all that artifacts including two private final fields (type and weight), a constructor, two accessors methods having the same name as the fields (type() and weight()), and the trilogy containing hashCode(), equals(), and toString(). We can easily see the code generated by the compiler by calling the javap tool on MelonRecord class:
Figure 4.1 – The code of a Java record
Pay attention that these accessor’s names don’t follow the Java Bean convention, so there is no getType() or getWeight(). There is type() and weight(). However, you can explicitly write these accessors or explicitly add the getType()/getWeight() getters – for instance, for exposing defensive copies of fields.All these stuff are built based on the parameters given when we declare a record (type and weight). These parameters are also known as the components of the record and we say that a record is built on the given components.The compiler recognizes a Java record via the record keyword. This is a special type of class (exactly as enum is a special type of Java class) declared as final and automatically extending java.lang.Record. Instantiating MelonRecord is the same as instantiating the Melon class. The following code creates a Melon instance and a MelonRecord instance:
Melon melon = new Melon(“Cantaloupe”, 2600);
MelonRecord melonr = new MelonRecord(“Cantaloupe”, 2600);
Java records are not an alternative to mutable JavaBean classes. Moreover, you may think that a Java record is just a plain transparent approach for carrying immutable data or an immutable state (we say “transparent” because it fully exposes its state, and we say “immutable” because the class is final, it has only private final fields, and no setters). In this context, we may think that Java records are not quite useful because they just overlap the functionality that we can obtain via Lombok or Kotlin. But as you’ll see in this chapter, a Java record is more than that, and it provides several features that are not available in Lombok or Kotlin. Moreover, if you benchmark, you’ll notice that using records has significant advantages in the performance context.