95. Using generic records in record patterns
Declaring a generic record for mapping fruit data can be done as follows:
public record FruitRecord<T>(T t, String country) {}
Now, let’s assume a MelonRecord which is a fruit (actually, there is a controversy if a melon is a fruit or a vegetable, but let’s say that it is a fruit):
public record MelonRecord(String type, float weight) {}
We can declare a FruitRecord<MelonRecord> as follows:
FruitRecord<MelonRecord> fruit =
new FruitRecord<>(new MelonRecord(“Hami”, 1000), “China”);
This FruitRecord<MelonRecord> can be used in record patterns with instanceof:
if (fruit instanceof FruitRecord<MelonRecord>(
MelonRecord melon, String country)) {
System.out.println(melon + ” from ” + country);
}
if (fruit instanceof FruitRecord<MelonRecord>(
var melon, var country)) {
System.out.println(melon + ” from ” + country);
}
Or, in switch statements/expressions:
switch(fruit) {
case FruitRecord<MelonRecord>(
MelonRecord melon, String country) :
System.out.println(melon + ” from ” + country); break;
default : break;
};
So, Java Generics can be used in records exactly as in regular Java classes. Moreover, we can use them in conjunction with record patterns and instanceof/switch.
96. Handling nulls in nested record patterns
From Chapter 2, Problem 49, we know that starting with JDK 17 (JEP 427), we can treat a null case in switch as any other common case:
case null -> throw new IllegalArgumentException(…);
Moreover, from Problem 62, we know that, when type patterns are involved as well, a total pattern matches everything unconditionally including null values (known as an unconditional pattern). Solving this issue can be done by explicitly adding a null case (as in the previous snippet of code) or relying on JDK 19+. Starting with JDK 19, the unconditional pattern still matches null values only that it will not allow the execution of that branch. The switch expressions will throw a NullPointerException without even looking at the patterns.This statement partially works for record patterns as well. For instance, let’s consider the following records:
public interface Fruit {}
public record SeedRecord(String type, String country)
implements Fruit {}
public record MelonRecord(SeedRecord seed, float weight)
implements Fruit {}
public record EggplantRecord(SeedRecord seed, float weight)
implements Fruit {}
And, let’s consider the following switch:
public static String buyFruit(Fruit fruit) {
return switch(fruit) {
case null -> “Ops!”;
case SeedRecord(String type, String country)
-> “This is a seed of ” + type + ” from ” + country;
case EggplantRecord(SeedRecord seed, float weight)
-> “This is a ” + seed.type() + ” eggplant”;
case MelonRecord(SeedRecord seed, float weight)
-> “This is a ” + seed.type() + ” melon”;
case Fruit v -> “This is an unknown fruit”;
};
}
If we call buyFruit(null) then we will get the message, Ops!. The compiler is aware that the selector expression is null and that there is a case null therefore it will execute that branch. If we remove that case null then we immediately get a NullPointerException. The compiler will not evaluate the record patterns; it will simply throw a NullPointerException.Next, let’s create an eggplant:
SeedRecord seed = new SeedRecord(“Fairytale”, “India”);
EggplantRecord eggplant = new EggplantRecord(seed, 300);