On 09/18/2013 12:54 PM, Vitaly Davidovich wrote:
Rémi,
Sorry, using performance due to indirection and missed escape analysis
as reason for not making Optional serializable is just silly.
You miss the point here, it's not a bug or an issue with the escape
analysis,
the reference escape, it's how the code is written if you declare a
field Optional
so the boxing will be never removed by using escape analysis.
It's exactly like using a wrapper type instead of a primitive type when
you declare a field.
and if you want to serialize a field which is Optional, there is no
issue, mark it transient, use orNull() when serializing and
fromNullable() when deserializing, BTW it will be better if you decide
that the field can not store null in a future version.
It's not going to prevent people from using this type as a field
(docs/guidance is a better way to steer people in the right direction).
Why not having both ?
This is IMO similar to what Martin Thompson calls mechanical sympathy, I
prefer to live in a world
where the JDK API and the VM works in harmony.
Optional is nice from the API point of view, but not if you store it in
a field.
If it's not something that should be stored in field, there is no point
to make it serializable.
Using your logic, may as well argue that no wrapper/datastructure
class be used at all that has a couple of impls and an interface/base
class.
no, the trade off is not the same.
If you use Optional for every fields, we already know that it doesn't
work at all. Because this is how the VMs were working before 2000.
And if JIT cannot remove the box for whatever reason, should we not
allow Optional at all? :)
If people don't want to see the trade off behind it, may be you're right,
but I think that the Java community is more mature than that.
Cheers
Rémi
Sent from my phone
On Sep 18, 2013 2:41 AM, "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
