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.
