Data classes

[forax at univ-mlv.fr]

I agree that there is no way in Java to say that a field is null or not but we also commonly uses Objects.requireNonNull as precondition to indicate in our code to indicate if field can be null or not (by example IDEA adds Objects.requireNonNull by default).
I heard your concern about not trying to solve the nullability support in Java but at the same time, we do not write the constructor, equals or hashCode the same way if a field can be null or not, so it the kind of an information you want to tailor the code the compiler/JDK will generate, so the coupling is not weak.

In the proposal, you discuss about adding keywords like "non-final, unfinal, mutable", i.e. considering that there can be a different set of keywords for data class declaration which is different from the one we have on fields. In that spirit, we can have a flag like nullable, maybenull, etc to specify that the compiler will not generate a requireNonNull inside the principal constructor and that equals or hashCode do not need nullchecks.

Rémi 

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 2 Novembre 2017 15:05:29
> Objet: Re: Data classes

> Yes, there are many features that a feature like data classes might want
> to pull in, like nullability / optionality / named constructor parameter
> invocations, to name a few.
> 
> However, treating nullability as a sub-feature of data classes would be
> a mistake, because, if a user has a class that does not quite meet the
> requirements for a data class, users will be badly tempted to wedge this
> square peg into the round data class hole just to get, say, nullability
> support.  If we're going to do something about nullability, it should
> work for all classes, data or otherwise.
> 
> You are right that there's a weak coupling, in that if we did that
> feature first, it might affect the defaults for data classes, whereas if
> we do data classes first, we might be boxed in with respect to defaults.
> 
> 
> 
> On 11/2/2017 9:34 AM, Remi Forax wrote:
>> Hi Brian,
>> there is an axis which is not mentioned in this document, the nullablility of
>> the fields, it's somewhat like 'final' because fields should not non nullable
>> by default, it asks the compiler to add codes in the constructors (the calls to
>> requireNonNull) so it can have a not so simple interaction with the call to
>> default.
>>
>> I will post several other mails on each sections later.
>>
>> cheers,
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>> Envoyé: Mercredi 1 Novembre 2017 19:53:40
>>> Objet: Data classes
>>> At the following URL, please find a writeup containing our current
>>> thoughts on Data Classes for Java:
>>>
>>>      http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>>>
>>> Comments welcome!
>>>
> >> We'll be making a prototype available soon for folks to play with.