Updated Draft specs for JEP 359 (Records)

Gavin Bierman gavin.bierman at oracle.com
Fri Nov 15 16:20:55 UTC 2019

Thanks Maurizio

> On 31 Oct 2019, at 14:29, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> Related to the earlier discussion on forbidden record members - how is this section still relevant?
> "It is a compile-time error for a record declaration to declare a record component with the name clone, finalize, getClass, hashCode, notify, notifyAll, readObjectNoData, readResolve, serialPersistentFields, serialVersionUID, toString, wait, or writeReplace."
> Chris says that the serialization spec ignores all the serialization-related methods if they appear inside a record; should we lift the restrictions?

Yes, we’re going to update this part of the spec. I will write separately about this.

> In the grammar for records, I find it odd that we basically say that record members are class members plus compact constructor, but then we revert to say that instance initializer are not allowed.
> I wonder if a more specific production for the record body would be useful and more direct here?

I think this is a style thing, but I’m keen to reuse the class grammar. 

> I note an asymmetry between the rules for canonical constructor and compact constructor; in one we say:
> "Every field corresponding to a record component of R must be definitely assigned and moreover not definitely unassigned (16.9) at the end of the body of the canonical constructor."
> In the other we say:
> "It is a compile-time error if at the end of the body of the compact constructor, any of the fields corresponding to the record components of R are neither definitely assigned nor definitely unassigned.”

Indeed. Although I can remove both as we get this by virtue of the fields being blank final instance variables (JLS 

> Moreover, a deeper question: should we leave the magic auto-initialization of fields only for the compact form? That way, you would have a _new_ linguistic form, with _new_ properties, whereas old forms (e.g. a constructor with parameters) will have same rules as before (can have returns, must initialize fields explicitly). I think that, from a pedagogical aspect, that would be preferrable.

That’s what we do.


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

More information about the amber-spec-experts mailing list