Updated document on data classes and sealed types
Brian Goetz
brian.goetz at oracle.com
Fri Mar 15 22:32:21 UTC 2019
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>
More information about the amber-spec-experts
mailing list