I think the point is that not marking Optional as Serializable as some form of preventive measure to make people not use them as fields due to performance is misguided - it's not going to achieve that, it's just going to annoy people and prompt emails like this. There may be cases where you just don't care about the perf/footprint impact of having the box - this should be left up to user, not crippling Optional.
Vitaly Sent from my phone On Sep 18, 2013 10:35 AM, "Remi Forax" <[email protected]> wrote: > 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 >> >> >> >> >
