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 <[email protected] <mailto:[email protected]>>
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" <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
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"
<[email protected] <mailto:[email protected]>>
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
