Records and serialization

[Brian Goetz]

So far, we've taken a middle-of-the-road position on records and 
serialization, where we generate a `readResolve()` method that pipes the 
at-rest state through the canonical constructor, to gain the benefit of 
validation checks.  Some have argued to do less, but I think we can do a 
little more, and in light of the direction outlined earlier today for 
serialization, we should do more.

The semantics of a record are that we derive all of an object's standard 
protocols -- construction, deconstruction (whether through pattern match 
or accessors), equality, hashing, and string representation -- from the 
state description.  Deriving the serialization protocol from the state 
description similarly makes sense.  Which would mean: the state 
description is also the serialized form.  So not only do we want to 
generate a readResolve() method as we currently have, but we probably 
want to prohibit specifying explicit readResolve(), readObject(), and 
writeObject() methods (and other serialization knobs) on Serializable 
records -- the canonical constructor should be the line of defense 
against bad data for both the front-door and back-door APIs.

This also, as it turns out, yields the serialization protocol we'd get 
if we implicitly marked the canonical constructor with `@Deserializer` 
and the canonical deconstruction pattern with `@Serializer`, as per the 
doc dropped today.