> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mardi 12 Mars 2019 00:39:46 > Objet: Re: The gift that keeps on giving
> Heh, because by " I’m working on a story here, but for now, let’s just put > this > on the list of legacy pain that we will eventually have to deal with” I meant > “let’s all design this off the top of our heads right now” :) > Yes, generating an insecure all-fields ctor and pushing the scraped fields to > it > is one possibility (as is the readResolve/writeReplace protocol.) But I’d like > to do something better. Stay tuned. ok, cool ! Rémi >> On Mar 11, 2019, at 7:21 PM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] >> wrote: >> oops, i've forgotten to mention that the constructor / factory method known >> by >> the serialization should work like a copy constructor. >> with your example: >> value class X implements Serializable { >> int x; >> public X() { x = 0; } >> public X withX(int x) { >> ALOAD this >> ILOAD x >> WITHFIELD “x” >> ARETURN >> } >> // this constructor is required by the deserialization mechanism otherwise it >> doesn't compile >> private X(X unsafeXThatComesFromSerialization) { >> this.x = unsafeXThatComesFromSerialization.x; // checks the arguments here >> } >> } >> Rémi >> ----- Mail original ----- >>> De: "Brian Goetz" < [ mailto:brian.go...@oracle.com | >>> brian.go...@oracle.com ] > >>> À: "Remi Forax" < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > >>> Cc: "valhalla-spec-experts" < [ >>> mailto:valhalla-spec-experts@openjdk.java.net | >>> valhalla-spec-experts@openjdk.java.net ] > >>> Envoyé: Lundi 11 Mars 2019 23:53:14 >>> Objet: Re: The gift that keeps on giving >>> Well, consider this value: >>> value class X { >>> int x; >>> public X() { x = 0; } >>> public X withX(int x) { >>> ALOAD this >>> ILOAD x >>> WITHFIELD “x” >>> ARETURN >>> } >>> } >>> How do I serialize new X().withX(3) ? How do I deserialize it with the lame >>> ctor that X has? >>> If you pull on that string, what you end up with is a secret constructor / >>> factory that takes one arg per field and initializes all the fields with no >>> invariant checking, and serialization scraping the fields and >>> deserialization >>> calling that constructor. Which is about as awful as existing serialization >>> (with all the security risks it entails). So, let’s call that our last >>> choice, >>> and look for something better :) >>>> On Mar 11, 2019, at 5:26 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr | >>>> fo...@univ-mlv.fr ] > wrote: >>>> Hi Brian, >>>> given that a value type is constructed by a factory method (the >>>> constructor is >>>> desugared to a static method), why not making the serialization aware of >>>> that >>>> factory method. >>>> Rémi >>>> ----- Mail original ----- >>>>> De: "Brian Goetz" < [ mailto:brian.go...@oracle.com | >>>>> brian.go...@oracle.com ] > >>>>> À: "valhalla-spec-experts" < [ >>>>> mailto:valhalla-spec-experts@openjdk.java.net | >>>>> valhalla-spec-experts@openjdk.java.net ] > >>>>> Envoyé: Lundi 11 Mars 2019 20:30:09 >>>>> Objet: The gift that keeps on giving >>>>> One thing we need to figure out about value types is … serialization. >>>>> (Pause for everyone to wishfully say “can’t we just disallow it for >>>>> values?”, >>>>> and three pauses for people to get over this.) >>>>> The problem is that serialization today proceeds by mutation, which might >>>>> be >>>>> something we could deal with, but the mechanisms for “safer” serialization >>>>> (readObject, etc) also rely on mutation, and that’s harder. >>>>> I’m working on a story here, but for now, let’s just put this on the list >>>>> of >>>>> legacy pain that we will eventually have to deal with.
