The gift that keeps on giving

[Brian Goetz]

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 <forax at 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.goetz at oracle.com>
>> À: "valhalla-spec-experts" <valhalla-spec-experts at 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.