Updated document on data classes and sealed types

[Remi Forax]

> 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 < [ mailto:brian.goetz at oracle.com |
> 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 < [ mailto:brian.goetz at oracle.com |
>> > brian.goetz at oracle.com ] > wrote:

>> > I've updated the document on data classes here:

>>> [ http://cr.openjdk.java.net/~briangoetz/amber/datum.html |
>> > 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. | [ mailto:kevinb at google.com |
> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190315/7ed77cd4/attachment.html>