Shouldn't Optional be Serializable?

[Eamonn McManus]

> yes and no,
> it depends how your RPC framework map errors because if you send an
Optional
> and then throw an exception in the client you will not have a meaningful
stack trace.

I don't understand what this means. Concretely, why would you not want
Optional<Something> to be a valid return type of an RMI method?

Éamonn


2013/9/19 Remi Forax <forax at univ-mlv.fr>

> On 09/18/2013 07:32 PM, Pete Poulos wrote:
>
>> One use case to consider here is RPC. many RPC frameworks use
>> serialization
>> to transmit the results of the RPC call over the network. If Optional is
>> not serializable then you will be unable to return Optional results from
>> methods invoked via RPC.
>>
>
> yes and no,
> it depends how your RPC framework map errors because if you send an
> Optional
> and then throw an exception in the client you will not have a meaningful
> stack trace.
>
> Rémi
>
>
>  On Sep 18, 2013 11:13 AM, "Joseph Unruh" <josephcu at gmail.com> wrote:
>>
>>  While It's clear that there are performance implications to using an
>>> Optional field, keeping Optional non-serializable doesn't do much to
>>> prevent that from happening. In the vast majority of cases, Optional will
>>> be used in a non-serialized context. So, as preventative measures go,
>>> this
>>> isn't a very effective one.
>>>
>>> Second, Optional exists primarily as a mechanism for marking that an
>>> object
>>> may be null. This is a design objective. If the objective was
>>> performance,
>>> then Optional wouldn't exist. Enforcing this usage on people,
>>> particularly
>>> in the narrow context of serialization, is a premature optimization. If
>>> it's useful to have optional exist at the API level in order to prevent
>>> NPEs, why can't it be useful at the individual class level to prevent
>>> NPEs?
>>>
>>> Cheers,
>>>     Joseph
>>>
>>>
>>> On Tue, Sep 17, 2013 at 11:37 PM, Remi Forax <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
>>>>>
>>>>>> 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> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>