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 <g...@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 <jad.na...@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 <jad.na...@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 <g...@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 <jad.na...@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.na...@imply.io > > >> > > > >> > > > > > > > > > -- > > > Jad Naous > > > Imply | VP R&D > > > 650-521-3425 > > > jad.na...@imply.io > > > > > > > > > -- > > Jad Naous > > Imply | VP R&D > > 650-521-3425 > > jad.na...@imply.io > > >