Shouldn't Optional be Serializable?
pete.poulos at gmail.com
Fri Sep 27 14:24:15 PDT 2013
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?
On Sep 21, 2013 1:38 PM, "Simone Bordet" <simone.bordet at gmail.com> wrote:
> 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
> >> > 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
> 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
More information about the jdk8-dev