Shouldn't Optional be Serializable?

roger riggs roger.riggs at oracle.com
Wed Sep 18 06:03:44 PDT 2013


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.

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
>>>>
>>>>
>



More information about the jdk8-dev mailing list