> De: "Brian Goetz" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > 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:[email protected] | [email protected] ] >> 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:[email protected] | >>> [email protected] ] > >>> À: "Remi Forax" < [ mailto:[email protected] | [email protected] ] > >>> Cc: "valhalla-spec-experts" < [ >>> mailto:[email protected] | >>> [email protected] ] > >>> 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:[email protected] | >>>> [email protected] ] > 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:[email protected] | >>>>> [email protected] ] > >>>>> À: "valhalla-spec-experts" < [ >>>>> mailto:[email protected] | >>>>> [email protected] ] > >>>>> 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.
