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.
> On Mar 11, 2019, at 7:21 PM, 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" <brian.go...@oracle.com>
>> À: "Remi Forax" <fo...@univ-mlv.fr>
>> Cc: "valhalla-spec-experts" <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 <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" <brian.go...@oracle.com>
>>>> À: "valhalla-spec-experts" <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.
