Re: Nulls vs Optional

[Jihoon Son <ji...@apache.org>]

I find using Optional useful and safer especially for interfaces and public
methods.
Even though the NPE happens very rarely in production, but we do have some
in edge cases.
(
https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordinator/HttpLoadQueuePeon.java#L378
is
an example. I'm sorry that I haven't fixed this bug yet even though I found
it a long time ago. The 'callback' is nullable which can lead to NPE if
'stopped' is true.)
But, at the same time, it might not be a good idea to use Optional
everywhere, especially performance-sensitive codes.
I guess we need to figure out where we should use nulls and Optionals.

On Mon, Dec 30, 2019 at 10:37 AM Gian Merlino <gi...@apache.org> wrote:

> FYI: In https://github.com/apache/druid/pull/9111 I've used Optional a bit
> more; for example see HashJoinSegmentStorageAdapter#getClauseForColumn and
> Exprs.decomposeEquals. There are still a lot of @Nullable where needed to
> interact with existing interfaces. I didn't think going on a rampage
> changing them was a good idea.
>
> Curious what you all think. I'm wondering if we can articulate as a
> community a coherent null vs. optional policy. Otherwise in practice it
> will end up being personal preference of the author.
>
> On Fri, Oct 11, 2019 at 6:37 AM Jad Naous <ja...@imply.io> wrote:
>
> > I don't think we need to enforce the use of Optional (at least not to
> begin
> > with), but it would be a good idea to use it in new code.
> >
> > On Fri, Oct 11, 2019 at 6:35 AM Jad Naous <ja...@imply.io> wrote:
> >
> > > On using Optional: to me, it was mostly a documentation issue, making
> it
> > > easier to no longer have to worry about whether some method will return
> > > null or whether someone will pass null to a method. It also made it
> > easier
> > > to remember to actually check for the existence of something before
> using
> > > it. We also used Guava's Optional which is much more pleasant to work
> > with
> > > than the JDK's Optional.
> > >
> > > On Thu, Oct 10, 2019 at 5:46 PM Gian Merlino <gi...@apache.org> wrote:
> > >
> > >> For reference, a (brief) earlier conversation about this:
> > >> https://github.com/apache/incubator-druid/issues/4275, which links to
> > >>
> >
> https://github.com/apache/incubator-druid/pull/4254#discussion_r116628607
> > >> ,
> > >> which links to
> > >>
> > >>
> >
> https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555
> > >> .
> > >>
> > >> I really enjoyed programming with Scala's Option type, back when I had
> > >> spend a couple of years writing Scala code. They are awesome. Java
> > >> Optionals are sadly not quite as good, especially in ecosystem support
> > >> (they're not adopted very well in libraries or in the jdk itself) but
> > also
> > >> in functionality (in Scala they're tightly integrated into the
> > collections
> > >> library, which allows for some nice idioms).
> > >>
> > >> After that Scala break, when I came back to Java I wrote a lot of the
> > >> indexing service module. You can tell because it has Guava Optionals
> > >> everywhere. I mostly used it the way that Goetz recommended, as a
> method
> > >> return type in commonly used interfaces or utility methods. It was a
> bit
> > >> clunky but it was overall nice. I don't regret it. But now I mostly
> > don't
> > >> use them anymore, and started using null-returns (with @Nullable
> > >> annotations) instead since it jives better with the rest of the
> > codebase.
> > >>
> > >> Jad, or anyone else, have you worked on Java codebases where Optional
> > was
> > >> heavily used? What was the experience like?
> > >>
> > >> Also, has anyone had experience introducing a preference for Optionals
> > >> into
> > >> a large pre-existing codebase?
> > >>
> > >> On Wed, Oct 9, 2019 at 12:46 PM Jad Naous <ja...@imply.io> wrote:
> > >>
> > >> > Sir Tony Hoare on inventing null while working on ALGOL (from
> > wikipedia
> > >> > below):
> > >> >
> > >> > Speaking at a software conference called QCon London
> > >> > <https://qconlondon.com/> in 2009, he apologised for inventing the
> > null
> > >> > reference <https://en.wikipedia.org/wiki/Null_pointer>:[23]
> > >> > <https://en.wikipedia.org/wiki/Tony_Hoare#cite_note-23>
> > >> >
> > >> > I call it my billion-dollar mistake. It was the invention of the
> null
> > >> > reference in 1965. At that time, I was designing the first
> > comprehensive
> > >> > type system for references in an object oriented language (ALGOL W
> > >> > <https://en.wikipedia.org/wiki/ALGOL_W>). My goal was to ensure
> that
> > >> all
> > >> > use of references should be absolutely safe, with checking performed
> > >> > automatically by the compiler. But I couldn't resist the temptation
> to
> > >> put
> > >> > in a null reference, simply because it was so easy to implement.
> This
> > >> has
> > >> > led to innumerable errors, vulnerabilities, and system crashes,
> which
> > >> have
> > >> > probably caused a billion dollars of pain and damage in the last
> forty
> > >> > years.
> > >> >
> > >> > How about we stop passing nulls around as method arguments, field
> > >> values,
> > >> > return values, etc and use Optional instead? Benefits:
> > >> > - No more NPEs
> > >> > - Better documentation through code
> > >> > - Less mistakes
> > >> >
> > >> > I'm not suggesting we go rewrite everything, but rather just
> starting
> > to
> > >> > only return and accept Optionals in methods/constructors/etc.
> > >> >
> > >> > Jad.
> > >> >
> > >> > --
> > >> > Jad Naous
> > >> > Imply | VP R&D
> > >> > 650-521-3425
> > >> > jad.naous@imply.io
> > >> >
> > >>
> > >
> > >
> > > --
> > > Jad Naous
> > > Imply | VP R&D
> > > 650-521-3425
> > > jad.naous@imply.io
> > >
> >
> >
> > --
> > Jad Naous
> > Imply | VP R&D
> > 650-521-3425
> > jad.naous@imply.io
> >
>