> yes and no, > it depends how your RPC framework map errors because if you send an Optional > and then throw an exception in the client you will not have a meaningful stack trace.
I don't understand what this means. Concretely, why would you not want Optional<Something> to be a valid return type of an RMI method? Éamonn 2013/9/19 Remi Forax <[email protected]> > On 09/18/2013 07:32 PM, Pete Poulos wrote: > >> One use case to consider here is RPC. many RPC frameworks use >> serialization >> to transmit the results of the RPC call over the network. If Optional is >> not serializable then you will be unable to return Optional results from >> methods invoked via RPC. >> > > yes and no, > it depends how your RPC framework map errors because if you send an > Optional > and then throw an exception in the client you will not have a meaningful > stack trace. > > Rémi > > > On Sep 18, 2013 11:13 AM, "Joseph Unruh" <[email protected]> wrote: >> >> While It's clear that there are performance implications to using an >>> Optional field, keeping Optional non-serializable doesn't do much to >>> prevent that from happening. In the vast majority of cases, Optional will >>> be used in a non-serialized context. So, as preventative measures go, >>> this >>> isn't a very effective one. >>> >>> Second, Optional exists primarily as a mechanism for marking that an >>> object >>> may be null. This is a design objective. If the objective was >>> performance, >>> then Optional wouldn't exist. Enforcing this usage on people, >>> particularly >>> in the narrow context of serialization, is a premature optimization. If >>> it's useful to have optional exist at the API level in order to prevent >>> NPEs, why can't it be useful at the individual class level to prevent >>> NPEs? >>> >>> Cheers, >>> Joseph >>> >>> >>> On Tue, Sep 17, 2013 at 11:37 PM, 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >
