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