Rémi, Sorry, using performance due to indirection and missed escape analysis as reason for not making Optional serializable is just silly. 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). 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. And if JIT cannot remove the box for whatever reason, should we not allow Optional at all? :)
Cheers Sent from my phone On Sep 18, 2013 2:41 AM, "Remi Forax" <[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] >> >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]> 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 >>>> >>>> >>>> >
