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.
