[draluy]

I understand most of your points, but I disagree when it comes to the Optional part of your article. As stated by Brian Goetz here (https://stackoverflow.com/questions/26327957/should-java-8-g...), the intent was not to use optional all the time as you suggest, going as far as to say "Optional allows you to completely remove NPEs from your program. ". No they do not, an optional can be null anyway. As explained by Mr Goetz, they should only be used when designing an API, to explain to the consumer that a result may not be returned: "you probably should never use it for something that returns an array of results, or a list of results; instead return an empty array or list. You should almost never use it as a field of something or a method parameter."

I think we should keep in mind this is a type added for the JDK code foremost, and use it in similar use cases, and not see it as a general replacement for nullable values.

[virgilp]

The big problem with java is that you don't have non-nullable versions for most types; in my mind, the biggest advantage of Option is the default implication that "everything that's not explicitly Optional is really non-optional". Alas, that's not true in Java - if you have a non-optional type, you can (almost) never be sure that the value is non-null. It feels like just adding Optional, they only did half of the job.

[Cthulhu_]

In this case the most pragmatic thing to do is to ensure nothing in your application can ever be null - use asserts during development, empty lists, null objects, etc. Also never catch NPE's, if there is one after all those precautions, it's a developer error / bug and should be punished as such.

The problem with optionals - as Sonar will complain about - is that people will call `.get()` on an Optional without first checking `.isPresent()` for example.

Lots of things in the language that allow you to shoot yourself in the foot that other languages have solved.

[hyperpallium]

Semantically, is that different from using a reference variable without first checking it !=null?

Also, isn't there a static code analysis tool that checks at compile-time that reference variables annotated as @non_nullable can never be null?

[AstralStorm]

There is exactly one place where you might want to catch an NPE: top level global exception handler for logging and debugging.

[struppi]

Absolutely. So, what I started to do in my java code: Before dereferncing anything for the first time, i add

    assert foo != null : "foo must not be null - remember to wrap optional data in Optional<T>"

Just make sure to run your program (or at least the tests) with the JVM flag "-ea"

[qznc]

What is the point? How is an assert better than a NullPointerException?

If asserts are disabled, then the null pointer checks are still inserted by the JVM.

[cpburns2009]

The benefit of using an assert is that it makes the error condition known immediately to the caller and the reason. Otherwise, whose to say when the NPE will occur. It could be raised just a couple lines down, or it could be a couple methods or a classes away which increases the complexity of diagnosing the actual cause of the error.

[ojhughes]

A more idiomatic approach would be Objects.notNull(foo)

[tobyhinloopen]

They cannot truly fix the problem without dropping backwards compatibility.

[virgilp]

That's only partially true (and it is harder to do now that they introduced Optional).

Think about it like this: in Java - all class references were Option<Class> by default - and what was truly lacking was the possibility of having a non-optional reference[1]. They could've treated transparently all old-code[2] references as Option<ClassName>, and just given you the possibility of having non-optional reference in the new code (that meant that you can't pass objects with non-optional references to the legacy libraries, but it's a pain that could've gone away pretty quickly as libraries got recompiled to the new java versions)

[1] Oracle's interpretation was the other way around: "Java lacks the Option type, let's add it". I argue they got it wrong - Java always had the Option type, it's just that it was implicit; and since Java was lacking the non-optional types, you couldn't do anything useful with the Option, other than check for "None" (i.e. null).

[2] By "old code" I mean "old compiled code". You keep the binary compatibility - but indeed, you would need to drop the source-level compatibility, since compiling old code with the new compiler would not have worked. But, again, that would be fixable with a "legacy syntax" compiler flag, that would produce old-style binaries from old-style source code.

[bonesss]

I'm not sure if it is going mainstream right away, but C# is trying an interesting solution to that same problem: reversing their default relationship with 'nulls' and adding in optional syntax to flag variables as 'nullable'.

In terms of backwards compatibility the language teams position, IIRC, was that in the cases where you are intentionally using null it's quite easy to find and flag flag the nullable variable, but in all other cases the unexpected nullability can responsibly be removed from apps, making then-unnecessary null checks superfluous.

It's a bold move, but if it works at scale Java might be able to pull the tablecloth out from under the plates too...

[yoz-y]

Could the add some non-nullable annotation like apple did when updating objective-c to play nicely with Swift's optionals?

[dep_b]

Non-nullable is a promise not a guarantee. It does absolutely nothing in terms of useful warnings or compiler errors within Objective-C, it only explains how Swift should consume the Objective-C API.

It's still entirely possible to get a nil from Objective-C while the API is declared as nonnullable, this even happened to me with Apple's own API's if abused to a certain limit.

[yoz-y]

Yes but if Java 10 (for example) introduced this annotation then the JVM10 could transform a null returned from a non-nullable annotated function to an exception. Compile time static checks could also be added to guarantee that such a method does not return null. But you could still use such a function from a previous java version albeit you would sacrifice the checks.

It is a way to introduce the benefits (as long as the library is developed properly) of non-nullable types without sacrificing retro compatibility.

Edit: I remember a bug in earlier version of Swift Cocoa binding where getting calendar events without titles would hang without possibility of recourse because of this problems.

[DougBTX]

Something like what they are trying for C# may work for Java too: https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-...

[yoz-y]

Returning an empty list or empty array is different from returning no list at all.

Imagine I want to query a database of tagged articles. Let's say I want to get articles with an exact set of tags.

Passing this method [A, B] will give me articles with tags A and B, passing this method [] will give me articles with no tags. Not specifying the query parameter at all will result in no parameter. I could use a boolean value to keep track of that or just use an optional.

[saltedmd5]

The point is that returning an Optional gives you nothing above returning a null - in fact it increases complexity and makes calling code more error-prone for no gain.

If your contract says you return a Foo, you could be returning a null. If you change that to Optional<Foo> you could still be returning a null.

It's not what Optionals are for. They are just widely misunderstood and abused.

[saltedmd5]

Thank you for calling this out. I have to fight this fight way too often.

Optional is really for functional code, not for "eliminating NPEs," because it doesn't do that - in fact it means strictly speaking you have to do additional checking.

The real purpose of optional is for allowing me to do things like `foo.first().orElseGet(other)`. `first` has to return an Optional rather than a null or it will blow up.

If you are doing `Optional.isPresent()` as a straight-up replacement for null checks then you are doing it wrong. If you want to avoid returning nulls and doing null checks, use polymorphic null objects.