> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>, "Kevin > Bourrillion" <kev...@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:kev...@google.com | <kev...@google.com> ] >>> À: "Amber Expert Group Observers" [ >>> mailto:amber-spec-observ...@openjdk.java.net >>> | <amber-spec-observ...@openjdk.java.net> ] >>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts@openjdk.java.net | >>> <amber-spec-experts@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.go...@oracle.com | >>> brian.go...@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.go...@oracle.com >>>>> | >>>> > brian.go...@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:kev...@google.com | >>> kev...@google.com ]
