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.hega...@oracle.com> wrote:
> 
> Gavin,
> 
>> On 8 Nov 2019, at 15:28, Gavin Bierman <gavin.bier...@oracle.com 
>> <mailto:gavin.bier...@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.



Reply via email to