Reminder about draft specs

[John Rose]

I like the (de-)serialization specification for records, because it is a minimum cut on the existing
specification.  A day may come when a new serialization is based on something like expression
trees which are executed to produce the deserialized values… but it is not THIS day, as Aragorn
might say.

In order to emphasize the incremental relation of record serialization to what has gone before,
it would be helpful (even if only as a blog post) to show how the effect of record serialization,
as documented in the proposed spec., would look if it were hand-coded using today’s
serialization.

I guess what I’m saying is that records can be demystified if they can be (as much as possible)
described in terms of the boilerplate you would be forced to write, if you wanted the proposed
behavior, but didn’t have the proposed feature.  Make sense?

— John

On Nov 8, 2019, at 9:11 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Gavin,
> 
>> On 8 Nov 2019, at 15:28, Gavin Bierman <gavin.bierman at oracle.com <mailto:gavin.bierman at oracle.com>> wrote:
>> 
>> ...
>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html <http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html>
> Looks good.  A comment relating to Serialization, from section 8.10.1 - Record Components.
> 
>  As all record types are subclasses of the class java.lang.Record which in turn implements the interface java.io.Serializable, it is necessary to …
> 
> 
> This is not true. j.i.Record does not implement Serializable. Not all records are serializable.
> 
> A record may be serializable, if it implements the java.io <http://java.io/>.Serializable interface, but it is not required. For example,
> 
>   record SerializableFoo (int x, int y) implements java.io.Serializable { }
> 
> Additionally, I thought that all serialization related magic members were to be restricted from being record component names ( they are just too odd and potentially confusing ) ? The spec has some, but not all. The complete list ( of 7 ) is:  writeObject, readObject, readObjectNoData, writeReplace, readResolve, serialVersionUID, serialPersistentFields.
> 
> -Chris.



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