On Sep 18 2013, at 06:03 , roger riggs wrote: > Hi Remi,, > > Optional has semantics beyond those of simple boxing including > throwing an exception if it has no value. The class libraries are > designed to be useful to developers as part of a whole data model > which includes serialization; optimizations of the API to enable > VM performance would, I think be considered if the API design can provide > the equivalent semantics. > > BTW, Optional.of(null) does not say it throws NPE; I didn't find any > specification that connects the "not null" on the @param to throwing NPE > in the class or package javadoc.
I've filed https://bugs.openjdk.java.net/browse/JDK-8025610 to correct this. Thank you. Mike > > Optional should be Serializable. > > $.02, Roger > > > On 9/18/2013 2:37 AM, Remi Forax 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 >>>>> >>>>> >> >
