Yes, you can dereference a null pointer and risk an exception. So don't do that.
See where this is going?
The problem with Java's optional is that it is by all appearances (in name and high-level description), a general purpose optional, albeit with a ton of gotchas that will result in people saying "Just don't do that."
Java's optional is not a general purpose option type. In fact, its intended use-case is very specific, according to a rather obscure SO answer by Brian Goetz: http://stackoverflow.com/a/26328555/547365
This is, of course, just tribal knowledge, meaning people are going to be doing shit with optional that they shouldn't, and it's going to be messy.
>Yes, you can dereference a null pointer and risk an exception. So don't do that.
Except these aren't at all the same. With a reference, you have no good way of telling whether your reference IS nullable. With Optional, it's ALWAYS optional.
Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks.
Sure pattern decomposition is nicer, but that doesn't mean that Java's implementation "defeats the purpose entirely" like the author suggests. I'd love everything to be checked statically, but if that can't be done, I still like strong conventions which make the code clearer and safer.
As the article mentions, we have annotations to do just that.
>Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks.
Again, if we're using static analysis to verify the correct use of Optional, why are we using optional at all? Why wouldn't we use static checks to verify null references can't be dereferenced, instead of hypothetical yet-to-be-implemented static checks that may not be implemented anyway? See https://github.com/findbugsproject/findbugs/issues/56
>As the article mentions, we have annotations to do just that.
Your mileage may vary, but my experience with nullable/nonnull annotations is that because they are not used across the board, you are either left with a ton of false positives or a ton of false negatives. The fact that there hasn't really been a great standardization in the core language is probably evidence of that (yes, JSR305 exists, but the JDK doesn't enforce its constraints by default).
With Optional, it's a clean slate. You can simply say "a reference to an Optional shall never be null" and you could probably enable such an enforcement for an existing project. Of course it's not going to be 100% while it's still a normal reference type, but catching 99% of the cases is a really big improvement!
https://kotlinlang.org/docs/reference/null-safety.html
It's simple:
val x: Foo = maybeGetSomeFoo() // Error: method returns Foo?
val x: Foo? = maybeGetSomeFoo()
x.sayHello() // Error: x may be null
x!!.sayHello() // OK, the !! method throws an exception if it's null
if (x != null) x.sayHello() // OK, flow sensitive typing means the test narrows the type
val h = x?.sayHello() // OK, ?. yields null if left hand side is null, otherwise evaluates right
val h = x?.sayHello() ?: return // OK, ?: runs right hand side only if left hand side is null
I am not sure there is a distinction. Though it is true that some analyses may be run by a broader swath of users.
1) A reference is @NonNull in my code, and I pass it to a component that accepts a regular reference as input. The annotation semantic is simply lost, and I may not even realize it as I'm writing that code. By comparison, if I need to pass an Optional<T> reference where a T reference is needed, then the type system reminds me to consider the present and absent cases. Optional does not allow the programmer to forget.
2) The fact that a component or library was written with annotations does not mean that all usage of the library will properly check the annotations. Sometimes people forget, or sometimes they interact with a component in a dynamic way like through Spring and the semantics get lost. An Optional makes this impossible to forget. You can confuse a @Nullable T with a T, or forget to check upon conversion, but there is no failure case that causes an Optional<T> to turn into a T without handling the present and absent cases.
More choice is better than less choice. You could design an Optional type to omit the get() method. That's less useful than what we have now. Like goto, it has rare but legitimate uses, and it's easy to avoid for the "right way" in the average case (don't use it, flag it during code review, and document the reason why when it's being used).
You do, a reference is ALWAYS nullable/optional. Just because people might expect a certain reference never to be null does not change that. You could equally as well as semantically expect an Optional never to be "optional" (it is just a matter of perspective). People who are too lazy to check for null might be too lazy to check isPresent() and both will give you, unsurprisingly, an exception.
java.util.Optional is really just yet another layer added to support laziness in software developers. To put it bluntly, write better manuals/JavaDocs if necessary and, most importantly, read them.
Good libraries allow their developers to be lazy.
It's the Java language that forces you to think about nulls, not Optional.
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.
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 :/
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").
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.
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...
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.
@jontro is saying that proper Optionals make it impossible (or at least, more difficult) to forget about the problem at compile time.
If only FindBugs would warn about calling get() without checking isPresent() first. There's an open FindBugs ticket for this: http://sourceforge.net/p/findbugs/feature-requests/302/
Yes, you can write get() and risk an exception. So don't do that. I'm still glad get() is present because there are times when the human knows the value will always be present, but sometimes in a way that can't be encoded in the type system. Alternatively, sometimes an absent value is an error and get() is an acceptable way to check-and-throw.
I agree with the suggestion that static analysis can be useful, though many users had that already with FindBugs or Fortify. If we're talking about annotations based analysis, then it only goes so far. Optional and streams provide useful new tools for documenting intentions from my perspective. Another reason I enjoy the type is because it makes it a little more reasonable to say that, at least in new code, all references are nonnull references by default, since they'd be Optional otherwise.