Updated document on data classes and sealed types

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "Kevin
> Bourrillion" <kevinb at google.com>
> Envoyé: Vendredi 15 Mars 2019 23:32:21
> Objet: Re: Updated document on data classes and sealed types

> 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.
Just for the record (heh), i don't care to write more characters to implement Comparable, but i care that because equals() is generated but compareTo() is hand written there will be hidden bugs, mostly a.equals(b) == true not being equivalent to a.compareTo(b) == 0 because of the overflows. 

so Comparable.compareTo is not really a method of a random interface because it has a dependency on equals. 

Rémi 

> On 3/15/2019 6:24 PM, Remi Forax wrote:

>>> De: "Kevin Bourrillion" [ mailto:kevinb at google.com | <kevinb at google.com> ]
>>> À: "Amber Expert Group Observers" [ mailto:amber-spec-observers at openjdk.java.net
>>> | <amber-spec-observers at openjdk.java.net> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <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/0ba907cd/attachment.html>