Shouldn't Optional be Serializable?
Remi Forax
forax at univ-mlv.fr
Sat Sep 21 10:25:57 PDT 2013
On 09/20/2013 07:55 PM, Eamonn McManus wrote:
> > 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?
Hi Éamonn,
yes, returning an Optional for a service means that you may return null
which is usually a bad practice,
given the overhead of being over the wire, it's usully better to throw
an exception with a meaningful error message.
>
> Éamonn
Rémi
>
>
> 2013/9/19 Remi Forax <forax at univ-mlv.fr <mailto: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
> <mailto: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 <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
>
>
>
>
>
More information about the jdk8-dev
mailing list