Shouldn't Optional be Serializable?

[Vitaly Davidovich]

I think the point is that not marking Optional as Serializable as some form
of preventive measure to make people not use them as fields due to
performance is misguided - it's not going to achieve that, it's just going
to annoy people and prompt emails like this.  There may be cases where you
just don't care about the perf/footprint impact of having the box - this
should be left up to user, not crippling Optional.

Vitaly

Sent from my phone
On Sep 18, 2013 10:35 AM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> On 09/18/2013 12:54 PM, Vitaly Davidovich wrote:
>
>>
>> Rémi,
>>
>> Sorry, using performance due to indirection and missed escape analysis as
>> reason for not making Optional serializable is just silly.
>>
>>
> You miss the point here, it's not a bug or an issue with the escape
> analysis,
> the reference escape, it's how the code is written if you declare a field
> Optional
> so the boxing will be never removed by using escape analysis.
> It's exactly like using a wrapper type instead of a primitive type when
> you declare a field.
>
> and if you want to serialize a field which is Optional, there is no issue,
> mark it transient, use orNull() when serializing and
> fromNullable() when deserializing, BTW it will be better if you decide
> that the field can not store null in a future version.
>
>    It's not going to prevent people from using this type as a field
>> (docs/guidance is a better way to steer people in the right direction).
>>
>>
> Why not having both ?
>
> This is IMO similar to what Martin Thompson calls mechanical sympathy, I
> prefer to live in a world
> where the JDK API and the VM works in harmony.
> Optional is nice from the API point of view, but not if you store it in a
> field.
> If it's not something that should be stored in field, there is no point to
> make it serializable.
>
>  Using your logic, may as well argue that no wrapper/datastructure class
>> be used at all that has a couple of impls and an interface/base class.
>>
>>
> no, the trade off is not the same.
> If you use Optional for every fields, we already know that it doesn't work
> at all. Because this is how the VMs were working before 2000.
>
>  And if JIT cannot remove the box for whatever reason, should we not allow
>> Optional at all? :)
>>
>>
> If people don't want to see the trade off behind it, may be you're right,
> but I think that the Java community is more mature than that.
>
>  Cheers
>>
>>
> Rémi
>
>  Sent from my phone
>>
>> On Sep 18, 2013 2:41 AM, "Remi Forax" <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>>
>>     There is a good reason to not allow Optional to implement
>>     Serializable,
>>     it promotes a bad way to use Optional, at least from the VM point
>>     of view.
>>
>>     For the VM, Optional is a boxing, very similar to a boxing to Integer
>>     (in fact it's a little better because Integer.valueOf is badly*
>>     specified in the JLS
>>     but that's another story).
>>
>>     so if you write:
>>     class Foo {
>>       private Optional<String> description;
>>
>>       public Optional<String> getDescription() {
>>          return description;
>>       }
>>     }
>>
>>     This implementation id bad for two reasons, the first one is that
>>     you have to do
>>     a double indirection so will double your chance to have a value
>>     that is not
>>     in the cache but in RAM when you want the underlying String.
>>     The second reason is that the VM will usually not be able to
>>     remove the
>>     boxing because the creation of Optional will be too far from the use.
>>
>>     There is a better implementation
>>     class Foo {
>>       private String description;  // warning nullable !
>>
>>       public Optional<String> getDescription() {
>>          return Optional.fromNullable(**description);
>>       }
>>     }
>>
>>     It's the same API from the user point of view, but the creation of
>>     Optional
>>     is in the same inline horizon that it's use if getDescription is
>>     inlined
>>     (and here given that the method is really small, the is a good
>>     chance).
>>     In that case the VM is able to remove the boxing and everybody is
>>     happy.
>>
>>     So making Optional serializable goes in the wrong direction.
>>
>>     cheers,
>>     Rémi
>>     * as we now now in 2013, it was less obvious when the decision was
>>     taken circa 2003.
>>
>>     On 09/18/2013 03:16 AM, Pete Poulos wrote:
>>
>>         Optional holds data and while the vast majority of use cases
>>         for Optional
>>         will be to immediately pull the value out and do something,
>>         that doesn't
>>         change the fact that it is still a data structure, somebody
>>         somewhere is
>>         going to need to serialize it for some reason.  The other data
>>         structures
>>         in the java.util package are Serializable so making Optional
>>         Serializable
>>         makes things consistent.
>>
>>         As far as I know the cost of adding Serializable to Optional
>>         is negligible,
>>         but the cost could be fairly significant to someone who needs
>>         to serialize
>>         it at some point and is unable to do so.
>>
>>         Anyhow, I'm currently designing a set of functional
>>         (immutable, persistent)
>>         data structures for JDK8+ and I'm debating replacing my
>>         "Maybe" class
>>         (functionally the same as Optional, but with Haskell's naming
>>         convention
>>         for this data structure) the JDK8 Optional and I'm concerned
>>         that the lack
>>         of Serializable on Optional would cause problems for potential
>>         users of my
>>         API.
>>
>>         I'm only using Optional/Maybe to wrap return values from
>>         methods so I can
>>         indicate missing/present values within my data structures, so
>>         I could
>>         conceivably use Optional and still support serialization.
>>
>>         Also, while we are having this discussion, is there an
>>         alternative to
>>         serialization that is considered superior?  Over the years I
>>         have read blog
>>         posts by people condemning serialization, but I don't recall
>>         seeing any
>>         alternatives suggested.
>>
>>         Thanks,
>>         Pete
>>
>>
>>
>>
>>
>>
>>         On Tue, Sep 17, 2013 at 5:32 PM, Vitaly Davidovich
>>         <vitalyd at gmail.com <mailto:vitalyd at gmail.com>>**wrote:
>>
>>             Presumably because you may want to have class fields that
>>             express
>>             nullability via Optional rather than null.  Whether that's
>>             a good design or
>>             not is a separate question; conceptually, I don't see a
>>             reason why Optional
>>             cannot support that.  For "reference", Google Guava's
>>             version is
>>             serializable.  If someone were to replace their use with
>>             jdk's Optional
>>             then they will hit exceptions if the owner class is
>>             serialized.
>>
>>             Sent from my phone
>>             On Sep 17, 2013 6:06 PM, "Remi Forax" <forax at univ-mlv.fr
>>             <mailto:forax at univ-mlv.fr>> wrote:
>>
>>                 On 09/17/2013 11:44 PM, Pete Poulos wrote:
>>
>>                     Shouldn't java.util.Optional be Serializable?  Is
>>                     there a good reason
>>
>>             for
>>
>>                     it not be?
>>
>>                 wrong question.
>>                 the right one is why do you want Optional to be
>>                 Serializable.
>>
>>                   Thanks,
>>
>>                     Pete
>>
>>                 cheers,
>>                 Rémi
>>
>>
>>
>>
>