Shouldn't Optional be Serializable?

[Pete Poulos]

It looks like the discussion on this is done.  I'm new to this list, what
is the procedure for something like this? Do I need to create a bug ticket
somewhere or submit a patch?

Thanks, Pete.
On Sep 21, 2013 1:38 PM, "Simone Bordet" <simone.bordet at gmail.com> wrote:

> Hi,
>
> On Sat, Sep 21, 2013 at 10:25 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> > On 09/20/2013 07:55 PM, Eamonn McManus wrote:
> >>
> >> > 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?
> >
> >
> > Hi Éamonn,
> > yes, returning an Optional for a service means that you may return null
> > which is usually a bad practice,
> > given the overhead of being over the wire, it's usully better to throw an
> > exception with a meaningful error message.
>
> Like Éamonn, I don't follow your reasoning.
> "Usually a bad practice", "usually better to throw" seem your
> opinions, and seem weak to base such an (important) decision on
> opinions only.
> Do you have more important insights that we're missing ?
>
> Does not throwing an exception via RMI have at least the same or even
> greater overhead than returning Optional ?
> Did you measure the overhead that retuning a serializable Optional
> produces ?
>
> Thanks !
>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>