Draft JLS spec for records

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 5 Septembre 2019 21:24:55
> Objet: Re: Draft JLS spec for records

[...] 

>> But i don't think it's a good idea to make all records "serializable" (in the
>> general sense) by default

> No one is suggesting that. Serialization was an example; OR mappers was another.
> These are examples of the general principle that "we want records to be
> instantiable by frameworks", which means they need a way to find the
> constructor reflectively.
Writing a wrapper class that is able to serialize any records is easy if the constructor is always public. 

Here you are moving from "the internal implementation and the external API are the same thing" to "and records are instantiable by frameworks", that's a huge leap. 

>> Java serialization is not the best mechanism, mostly because of its
>> implementation, but at least there is one thing right, being serializable is
>> opt-in.
>> I believe we should follow the same principle by allowing the constructor to be
>> public or private, you are opting for being serializable (in the general sense)
>> or not.

> Among other things, unless we're willing to have _yet a third_ default
> accessibility (one for classes, one for interfaces, and yet another for
> records), then the obvious thing people will type:

> record R(int x) {
> R { ... }
> }

> would leave the ctor as package-private, which is probably not what people want
> either. Nope.
It's exactly what you get with a class. 

> I sympathize with the concern that "public ctor is not the best thing to
> expose". Until someone offers something better, though, this is the best we've
> got so far.

We are circulating back to my first question, why the constructor has to be public. 

I don't understand why we have to make records different from classes on that subject. 
If the constructor is public then deserialization libraries can using it, otherwise it can't. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190905/ba96bc20/attachment.html>