[mzl]

For me, it is not about catching errors, it is about documentation.

In the codebase I work on most, all variables that can be marked final are marked final. That means that whenever I see a non-final variable, I know that something tricky is happening and I need to be extra careful in reading the code.

[chrislynch42]

This is my reasoning as well. Also I am currently returning Optionals from any method that can result in a null.

[derriz]

The problem is that java.util.Optional has no special syntactic support compared to the way optionality is supported in Kotlin for example. And it is barely used in the standard libraries. And many/most 3rd parties libraries don't use it. Thus you end up with multiple styles in your code base: in places checking for null, in other places extracting the value from an Optional. And the type system/language doesn't prevent an Optional reference itself being null.

The Optional class is typical of the halfassery that has accompanied many improvements to Java over the years. From java.util.logging to generics to streams, I'm invariably irritated by compromises particularly as they've decided that maintaining backward compatibility is now a secondary concern.

I've run out of patience in the direction Java has taken and I've been a user since 1.0.4 - I'm going to try Kotlin for my next project.

[cesarb]

Also, if you're interoperating with Kotlin, a nullable reference works better than an Optional. A Kotlin nullable reference compiles down to a reference with intellij's @Nullable annotation, and a Kotlin non-nullable reference compiles down to a reference with intellij's @NotNull annotation.

It also works in the opposite direction: a Java parameter or return value annotated as @Nullable (doesn't have to be intellij's, the Kotlin compiler understands several annotation libraries) will appear as a nullable reference to Kotlin code, and a @NotNull or @Nonnull annotation makes it appear as a non-nullable reference.

[kazagistar]

Coming from functional languages, I really really tried to make optional work in our code base. However, it's inability to interact with checked exceptions or even slightly unusual control flow make it a real pain. It feels like fighting the language. My current suggestion is to pick a nullability annotation, and then wire it through your compiler and IDE, so it tells you if you forgot null checks, or made a superfluous null check on something annotated non-null.

[chrislynch42]

I was surprised by the responses about Optionals. Will have to look into it. As an alternative I have been looking to use the following to guarantee that certain methods cannot/will not return null (below). Maybe that is the better way to go?

return Optional.ofNullable(applications).orElseThrow(NullPointerException::new);

return Optional.ofNullable(applications).orElse(new Application());