[records] Is null back?

[Sascha Kohlmann]

Hi to all,

I hope this is the correct place for comments about Records.

I've translated a Domain Model of a current project into records. The model contains a couple of immutable value objects. These are excellently suited to be implemented as records.

My observations

Change from old classes to records is simple for standard use cases. Dealing with different constructors is possible. Checking values and adjusting them if necessary is possible. I found it not very intuitive to use "this.value" if I don't see the instance variable. This may change later when we've more experience with records.

Null collections can be replaced by empty collections, so that null must not be returned.

With other null parameters, however, it is more difficult. I had got used to never giving back null since Java 8 if null is a possible input value. Instead I always return Optional<T>. This is only possible with records if I pass Optional<T> as parameter into the record. Nevertheless I have to check it again for null to replace it with Optional.empty() if necessary. And Optional<T> to pass as parameter value is not intuitive even if it shows the user that the parameter is nullable.

I therefore fear that there will be more NPEs if record is implemented in the same way as before.

Inheritance

Less problematic I see the deep dependence of name in inheritance. I have a

interface Identity {
    String id();
}

The corresponding record looks something like this:

record ConcreteId(String id) implements Identity {
    public ConcreteId {
        this.id = requireNonNull(id);
    }
}


Here I have a method name that has to become a parameter name so that I can use this parameter name again as instance variable name. Deep name coupling. I'm not sure if I like it yet.

Have fun :-)

-isk