The gift that keeps on giving

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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:forax at univ-mlv.fr | forax at 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.goetz at oracle.com | brian.goetz at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>> valhalla-spec-experts at 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:forax at univ-mlv.fr |
>>>> 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" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ] >
>>>>> À: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net |
>>>>> 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.