A few notes: (1) There is a very long-running project towards fixing static nullability problems (identified by IntelliJ). The way of fixing is always properly using/not using @Nullable and annotating all packages in the project with @EverythingIsNonNullByDefault (see https://github.com/apache/incubator-druid/pull/5957#discussion_r206792747, https://github.com/apache/incubator-druid/pull/8198). I don't believe this project will ever complete. It would be nice if we were able to have ratcheting ( https://robertgreiner.com/continuous-code-improvement-using-ratcheting/) for the number of "Nullability problems" inspection violations in the project in our TeamCity build, but unfortunately, this is not currently possible, too.
(2) However, I think (1) is more a purism than a stressing practical need, because I don't actually see NPE being a huge source of bugs in production. NPEs frequently bubble up in tests when you refactor code, but then you fix tests before committing the code. This is a slightly longer feedback loop than if these nullability problems didn't allow you to compile the code, but not dramatically. (3) With regard to nullability, it might be a better idea to make Druid a mixed Java/Kotlin project and write non-performance critical parts of code and tests in Kotlin. Kotlin has a very succinct syntax for handling nullability, among other benefits. On Fri, 11 Oct 2019 at 03:46, 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 > > >
