Records =?utf-8?Q?=E2=80=94_?=Dealing with nullable values

Arash Shahkar arash.shahkar at gmail.com
Sat Dec 14 22:01:09 UTC 2019


Hi,

I’ve been using Lombok for quite a while now to automatically generate boilerplate code for "data carrier" classes. However, a pattern I really like and have found to work very well is to verify non-nullity of all the fields that must not be null, and return an Optional<Field> from the accessor of a field if it’s allowed to have a null value. Consider:

@lombok.Value
class Person {

    String name;
    Gender gender;

    Person(String name, Gender gender) { … } // customize the constructor, verifying that name is defined and valid

    Optional<Gender> getGender() { // customize the accessor for gender, to make sure calling code deals with the possibility of gender being null
        return ofNullable(gender);
    }
}

Doing a similar thing with records is not possible, due to the fact that the accessor for gender has to exactly return a Gender. With the current specification for records, the only option is to do:

record Person(String name, Optional<Gender> gender) {
    …
}

Is this considered good practice? Do you suggest any alternatives?


More information about the amber-dev mailing list