EN
Java - why java.util.Optional is not serializable?
5 points
JDK Optional doesn't implements Serializable interface. So how can we work with this Optional when dealing with serialization?
Let's take a look at this example:
xxxxxxxxxx
1
private final Optional<Integer> age;
2
3
public Optional<Integer> getAge() {
4
return age;
5
}
Instead of using Optional as field like we see above, we can use Optional as return type from getter and create new instance on each getter invocation.
xxxxxxxxxx
1
private final Integer age; // diff1: without Optional
2
3
public Optional<Integer> getAge() {
4
// diff2: each method invocation return new Optional
5
return Optional.ofNullable(age);
6
}
Check this link to see how to solve common java serialization problem with full code example that I described above:
If we want to use serializable Optional, we can use Guava's Optional.
xxxxxxxxxx
1
package com.google.common.base;
2
3
public abstract class Optional<T> implements Serializable {
4
// ...
5
}
For contrast we can compare java.util optional internals:
xxxxxxxxxx
1
package java.util;
2
3
public final class Optional<T> {
4
// ...
5
}
Answer from Brian Goetz (JDK architect from Oracle)
The best parts from the emails:
Part 1
xxxxxxxxxx
1
Someone suggested maybe even renaming it to OptionalReturn
2
to beat users over the head with this design orientation
Part 2
xxxxxxxxxx
1
>> Presumably because you may want to have class fields that express
2
>> nullability via Optional rather than null.
3
>
4
> Using Optional as a field type doesn't seem to offer much.
5
>
6
> Would the Optional field be wrapped in accessors?
Part 3
xxxxxxxxxx
1
>>> wrong question.
2
>>> the right one is why do you want Optional to be Serializable.
Full email list:
xxxxxxxxxx
1
Brian Goetz brian.goetz at oracle.com
2
Fri Sep 27 17:46:18 PDT 2013
3
Previous message: Shouldn't Optional be Serializable?
4
Next message: Shouldn't Optional be Serializable?
5
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
6
Amplifying Mike's observations: this exploration is already covered ground.
7
The JSR-335 EG felt fairly strongly that Optional should not be on any more
8
than needed to support the optional-return idiom only. (Someone suggested
9
maybe even renaming it to OptionalReturn to beat users over the head with
10
this design orientation; perhaps we should have taken that suggestion.) I
11
get that lots of people want Optional to be something else. But, its not
12
simply the case that the EG "forgot" to make it serializable; they explicitly
13
chose not to. And there's certainly been no new data that has come to light
14
that would motivate us to set that choice aside at this point.
15
16
17
18
On Sep 28, 2013, at 2:15 AM, Mike Duigou wrote:
19
20
>
21
> On Sep 17 2013, at 16:32 , Vitaly Davidovich wrote:
22
>
23
>> Presumably because you may want to have class fields that express
24
>> nullability via Optional rather than null.
25
>
26
> Using Optional as a field type doesn't seem to offer much.
27
>
28
> Would the Optional field be wrapped in accessors?
29
>
30
> If it's not wrapped, the result is that orElse(default) gets spread across
31
the usage of the field which is a poor way to apply a default.
32
>
33
> If if it is wrapped, why not apply the default in the accessor or in the
34
setter and not bother with Optional?
35
>
36
>> Whether that's a good design or
37
>> not is a separate question;
38
>
39
> That's not generally how JDK expert groups think. Adding any feature to
40
intentionally support bad design wouldn't make much sense. Understanding the
41
dimensions of how a feature might be used is certainly something that the EG
42
spends a lot of time on. The choice of semantics, methods offered and
43
interfaces implemented isn't ever separated from the expected use cases.
44
Optional is a new class/feature to the JDK and it seemed appropriate to start
45
with a minimal implementation. Concern that Optional would be misused in
46
other use cases threatened to derail it's inclusion in Java entirely!
47
Optional is being added for the value it offers in "fluent" sequences of
48
statements. In this context use of Optional as a visible type or for
49
serialization isn't relevant.
50
>
51
>> conceptually, I don't see a reason why Optional
52
>> cannot support that. For "reference", Google Guava's version is
53
>> serializable.
54
>
55
> Guava's Optional certainly proves that it is technically possible (which
56
was probably already known anyway) but that doesn't address whether doing so
57
with the Java Optional would be a good idea or not.
58
>
59
>> If someone were to replace their use with jdk's Optional
60
>> then they will hit exceptions if the owner class is serialized.
61
>
62
> While the incompatibility is certainly unfortunate this is probably not a
63
sufficient reason by itself to make Java's Optional serializable.
64
>
65
> Mike
66
>
67
>> Sent from my phone
68
>> On Sep 17, 2013 6:06 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:
69
>>
70
>>> On 09/17/2013 11:44 PM, Pete Poulos wrote:
71
>>>
72
>>>> Shouldn't java.util.Optional be Serializable? Is there a good reason for
73
>>>> it not be?
74
>>>>
75
>>>
76
>>> wrong question.
77
>>> the right one is why do you want Optional to be Serializable.
78
>>>
79
>>> Thanks,
80
>>>> Pete
81
>>>>
82
>>>
83
>>> cheers,
84
>>> Rémi
85
>>>
86
>>>
87
>