Shouldn't Optional be Serializable?

Vitaly Davidovich vitalyd at gmail.com
Fri Sep 27 21:04:02 PDT 2013


It sounds like this should have been named something else entirely then,
not Optional.

I just don't buy the argument that omitting serializability, which would've
cost close to nothing to support and develop, is somehow going to steer
people in the "right" direction.  I buy this argument if there's some
non-negligible cost to adding a feature (perf loss, code maintenance, back
compat issues, complexity, etc) but that's not the case here.  Document the
intent behind this class in docs and let users make their own choice
afterwards.

As for storage in fields, it's possible that someone may want to use it as
a way to improve maintainability by making it more obvious that it's a
nullable value.  Someone may also have some small state objects that wrap
an Optional inside (possibly coming out of an operation that returns an
Optional), and may decide to serialize it somewhere (it could be just for
debugging, for example).  The point is it shouldn't matter in this specific
case - as mentioned, supporting serializability of this simple construct is
dirt cheap.  I think this is just over analysis, frankly.

Vitaly

Sent from my phone
On Sep 27, 2013 8:15 PM, "Mike Duigou" <mike.duigou at oracle.com> wrote:

>
> On Sep 17 2013, at 16:32 , Vitaly Davidovich wrote:
>
> > Presumably because you may want to have class fields that express
> > nullability via Optional rather than null.
>
> Using Optional as a field type doesn't seem to offer much.
>
> Would the Optional field be wrapped in accessors?
>
> If it's not wrapped, the result is that orElse(default) gets spread across
> the usage of the field which is a poor way to apply a default.
>
> If if it is wrapped, why not apply the default in the accessor or in the
> setter and not bother with Optional?
>
> >  Whether that's a good design or
> > not is a separate question;
>
> That's not generally how JDK expert groups think. Adding any feature to
> intentionally support bad design wouldn't make much sense.  Understanding
> the dimensions of how a feature might be used is certainly something that
> the EG spends a lot of time on. The choice of semantics, methods offered
> and interfaces implemented isn't ever separated from the expected use
> cases. Optional is a new class/feature to the JDK and it seemed appropriate
> to start with a minimal implementation.  Concern that Optional would be
> misused in other use cases threatened to derail it's inclusion in Java
> entirely!  Optional is being added for the value it offers in "fluent"
> sequences of statements.  In this context use of Optional as a visible type
> or for serialization isn't relevant.
>
> > conceptually, I don't see a reason why Optional
> > cannot support that.  For "reference", Google Guava's version is
> > serializable.
>
> Guava's Optional certainly proves that it is technically possible (which
> was probably already known anyway) but that doesn't address whether doing
> so with the Java Optional would be a good idea or not.
>
> >  If someone were to replace their use with jdk's Optional
> > then they will hit exceptions if the owner class is serialized.
>
> While the incompatibility is certainly unfortunate this is probably not a
> sufficient reason by itself to make Java's Optional serializable.
>
> Mike
>
> > 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