Draft JLS spec for records

[Brian Goetz]

>
>     There needs to be a deterministic,
>     mechanically-derivable-from-the-state-vector way to construct a
>     record instance.  Serialization, for example, would use this for
>     reconstructing the object; frameworks like O/R mappers would do
>     the same.  Allowing the user to withdraw the constructor from the
>     API would undermine this.
>
>
> Serialization is an opt-in mechanism, i've not problem with the 
> constructor of a record being always public if the record is marked as 
> Serializable.

I have a big, big problem with that.  I don't want the accessibility of 
the mandated members to depend on something as ephemeral as what 
interfaces you implement; this is a giant leap towards the slippery 
slope of "Please, can I have 37 knobs on the code generator, kthxbye".  
No knobs.  There are no knobs.

> 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.

> 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.

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.

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