Draft JLS spec for records

[Chris Hegarty]

Gavin,

On 23/08/2019 22:25, Gavin Bierman wrote:
> A draft language spec for records is available at:
> 
> http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.html
> ...


"It is a compile-time error for a record header to declare a record
  component with the name clone, finalize, getClass, hashCode, notify,
  notifyAll, readObjectNoData, readResolve, serialPersistentFields,
  toString, wait, or writeReplace."

TL;DR from a serialization POV, I think the above list is fine.

--

Specifically on the restricted component names coming from serialization.

The complete list of java.io.Serializable magic members:

  private void writeObject(java.io.ObjectOutputStream out) throws ..
  private void readObject(java.io.ObjectInputStream in) throws ..
  private void readObjectNoData() throws ..
  ANY-ACCESS-MODIFIER Object writeReplace() throws ..
  ANY-ACCESS-MODIFIER Object readResolve() throws ..

  private static final ObjectStreamField[] serialPersistentFields
  ANY-ACCESS-MODIFIER static final long serialVersionUID

Ok, so you have all three no-args methods, looks fine, no possible 
collision between component accessor and the magic method. We could 
however decided to just ban both readObject and writeObject, as they 
could be confusing to the reader. But if it is just a minimal list of 
no-args methods, then what you have is fine.

The listing of serialPersistentFields seems fine too, again possible 
collision with the record component field.

serialVersionUID is static, so doesn't need to need to be listed. Ok.


--

java.io.Externalizable is a lot less magic

   void readExternal​(ObjectInput in)
   void writeExternal​(ObjectOutput out)

There are no no-args methods, good. If we decided to ban readObject and 
writeObject above, then we could consider banning these two component 
names also ( for the same reason we would ban the former ).

--

Typo: there are two occurrences of "an record".

-Chris.