Shouldn't Optional be Serializable?

[Mike Duigou]

On Sep 18 2013, at 06:03 , roger riggs wrote:

> Hi Remi,,
> 
> Optional has semantics beyond those of simple boxing including
> throwing an exception if it has no value.  The class libraries are
> designed to be useful to developers as part of a whole data model
> which includes serialization;  optimizations of the API to enable
> VM performance would, I think be considered if the API design can provide
> the equivalent semantics.
> 
> BTW, Optional.of(null) does not say it throws NPE; I didn't find any
> specification that connects the "not null" on the @param to throwing NPE
> in the class or package javadoc.

I've filed https://bugs.openjdk.java.net/browse/JDK-8025610 to correct this. Thank you.

Mike

> 
> Optional should be Serializable.
> 
> $.02, Roger
> 
> 
> On 9/18/2013 2:37 AM, Remi Forax 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
>>>>> 
>>>>> 
>> 
>