Every reference in Java can be null. You should be thinking about it all the time.

It's the Java language that forces you to think about nulls, not Optional.

Wouldn't it be better to have a non-nullable type, akin to C++'s return by value? That way, instead of forcing the programmer to think, you are removing the problem that they would need to think about.

In other languages that use Option types more natively, like Scala, anything that isn't optional is assumed to just not be null: The compiler doesn't guarantee it (it's not as if it can, we are dealing with a JVM here) but it works in practice. I've not seen a NullPointerException in years.

Option has other advantages, like its compositional qualities (thanks to Option being a monad). So imagine the following code

def foo(x:Option[String]) = x.filter(_.length<10).map(_ + "More data")

If the function returns None if it receives either None or a string longer than 10 characters, and if we got Some("short "), foo will return Some("short More data"). The alternatives without an option type, involve at least a couple of branching statements, even if you have a non nullable type, to convert from nullable to not nullable, while Option does it all for us.

> I've not seen a NullPointerException in years [in Scala]

This sounds odd. Does your code never interface with Java libraries and frameworks? I envy you! It's all too easy to forget to wrap a suspect value from Java-land with an Option(..). And cumbersome even if you do remember.

And then, there's the code written by Scala novices who just love using nulls. Yes, yes, "code reviews", we all know they are always practiced all the time :/

The Scala landscape is very, very quickly creating their own libraries for similar popular Java libraries/frameworks. It is entirely possible to create an application, web or otherwise, that uses no Java libraries at all (save for the sbt dependency tree).

As for "Scala novices who just love using nulls", if you're seeing that, then the coder in question missed day 1 of Scala training, which is always "if you are writing the word null, you are doing something wrong" (right up there with "if you are writing the word var, you are probably doing something wrong").

Maybe, but if true that's still in the future. The OP claimed they hadn't seen a NPE "in years", which simply doesn't match my own experience.

As for novices: yes, novices tend to do that. They tend to miss, misremember or fail to put into practice what they should have learned on day 1. I've also seen senior devs who were not exactly newbies (in general) still using nulls because they don't grok Scala; the famous "you can program Fortran in any language". The reality of software development is that you have to deal with all these people.

Whilst non-nullable references are useful, that isn't what Option is trying to solve. The problem with null references is that when you're handed a reference to an object of type T - the type system is saying to you: "This is the contract I will honour". Except it doesn't when the reference is null.

However the functionality of a null reference type is useful, because it allows a function to return 'no value'. So the goal of an Option type should be to expose the contract for T when there's a value and remove the contract when there's no-value.

The programmer is then explicitly forced to acknowledge the two states that the value could be.

Shameless plug - My C# implementation of Option which is possibly the most complete example out there (at least in C# world):

https://github.com/louthy/language-ext/blob/master/LanguageE...

Or, indeed, C++'s references which are non-nullable.

> Exactly, it forces the programmer to think

It's a curious feature, the way you've described it. I have virtually no experience with Java so I'm looking at this from a totally foreign perspective. The authors considers it an ineffective feature because you still have to think about null checks, whereas you consider it an effective feature because it forces you to think about the problem instead of ignoring it.

I believe the point @jontro is making is that unsafe programming behavior is unsafe without regard to the language's constraints. Option simply makes it more difficult to behave unsafely. Of course a developer can still call .get() when the presence of a value is unknown, but the Option type lets them know they are being careless in doing so.

No, the author considers it ineffective because you are not forced to think about nulls at compile time. Of course, at run time they will explode in your face, so you still have to consider them eventually.

@jontro is saying that proper Optionals make it impossible (or at least, more difficult) to forget about the problem at compile time.

I remember that somebody try to defend Java because have references instead of pointers so not is necessary to be worried about null pointers .. Ja!