Updated Draft specs for JEP 359 (Records)

Brian Goetz brian.goetz at oracle.com
Thu Oct 31 15:29:28 UTC 2019


> "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?

But, I think we later decided we are not ignoring _all_ of the serialization-related methods — that a readResolve() method is OK.  

I think there’s a difference between these two rules — the one about component names clashing with serialization members, and the one about useless explicit serialization members.  A badly named component could _implicitly_ give rise to a method that serialization might call — which seems dangerous.  Whereas a serialization member that never gets called is less so.  So even if we are considering warnings for the latter category, I still think errors for this category is right.  

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

Absolutely we should leave the new behavior (magic initialization) for the new form.  A canonical constructor that is declared the old way should work like any other constructor.  No magic initialization, no special requirements (the DA requirements of all constructors wrt final fields are all the safety we need), no stricture against return (which was there to avoid making the magic initialization more complicated.






More information about the amber-spec-experts mailing list