Updated document on data classes and sealed types

[Brian Goetz]

Yes, if you specify readResolve explicitly, you'll get what you wrote.

As to "why Serialization but not Comparable": because serialization is, 
in some very real sense, a language feature (even though it dramatically 
pretends to be "just" a library feature) -- and one that has significant 
security impact.

In comparison (heh), Comparable is just a random library interface.

On 3/15/2019 6:24 PM, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Kevin Bourrillion" <kevinb at google.com>
>     *À: *"Amber Expert Group Observers"
>     <amber-spec-observers at openjdk.java.net>
>     *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>     *Envoyé: *Vendredi 15 Mars 2019 22:02:24
>     *Objet: *Re: Updated document on data classes and sealed types
>
>     Well, I thought of nothing to dislike about this. 99.9% of users
>     will never know or care that this is happening. Occasionally an
>     exception will just pop up when deserializing invalid data and it
>     would be hard to view that exception as a bad thing.
>     Cool....
>
>
> Hi Brian,
> I like it too, better that my proposal that requires a special 
> treatment of records in ObjectInputStream/ObjectOutputStream.
>
> I suppose readResolve() can be overriden ??
>
> And playing the devil advocate, you rule out the automatic 
> implementation of Comparable as been too magic but you are proposing 
> exactly the same mechanism for serialization (that's why i have not 
> proposed to used readResolve() in my previous mail).
> So i wonder if your position has changed on Comparable ?
>
> regards,
> Rémi
>
>
>
>     On Fri, Mar 15, 2019 at 12:45 PM Brian Goetz
>     <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>
>         There is (at least) one area of interaction with other
>         features that I want to nail down for records: serialization
>         (it’s like death and taxes, always catches up with you.)
>
>         My proposal here is simple: if a record is Serializable, we
>         inject an implementation of readResolve() that runs back
>         through the constructor; for a record Foo with components a,
>         b, and c, we’d get:
>
>             private Object readResolve() {
>                 return new Foo(a, b, c);
>             }
>
>         This doesn’t interfere with the serialization mechanism
>         (default vs readObject/writeObject), but does defend against
>         malicious streams that forge record contents, by piping them
>         back through the ctor which will do validation / normalization.
>
>         It may seem a little odd to do something here for records, but
>         not for everything else.  To that, I have two answers:
>
>          - Records are special in that we _can_ do this, and its
>         pretty hard to argue this is wrong (though perhaps slightly
>         slower);
>          - This is a down payment on a bigger story for serialization,
>         in the same key: leaning on the constructor to validate state
>         where possible.I’d rather records (and values) be safe out of
>         the gate, rather than having to patch them later, and worry
>         about older classfiles.
>
>
>         > On Mar 1, 2019, at 3:14 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>         >
>         > I've updated the document on data classes here:
>         >
>         > http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>         >
>         > (older versions of the document are retained in the same
>         directory for historical comparison.)
>         >
>         > While the previous version was mostly about tradeoffs, this
>         version takes a much more opinionated interpretation of the
>         feature, offering more examples of use cases of where it is
>         intended to be used (and not used).  Many of the "under
>         consideration" flexibilities (extension, mutability,
>         additional fields) have collapsed to their more restrictive
>         form; while some people will be disappointed because it
>         doesn't solve the worst of their boilerplate problems, our
>         conclusion is: records are a powerful feature, but they're not
>         necessarily the delivery vehicle for easing all the (often
>         self-inflicted) pain of JavaBeans.  We can continue to explore
>         relief for these situations too as separate features, but
>         trying to be all things to all classes has delayed the records
>         train long enough, and I'm convince they're separate problems
>         that want separate solutions.  Time to let the records train roll.
>         >
>         > I've also combined the information on sealed types in this
>         document, as the two are so tightly related.
>         >
>         > Comments welcome.
>
>
>
>     -- 
>     Kevin Bourrillion | Java Librarian | Google,
>     Inc. |kevinb at google.com <mailto:kevinb at google.com>
>

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