Java 8’s new Optional type doesn't solve anything
1–10 of 197 posts
Re: Java 8’s new Optional type doesn't solve anything
#2TL;DR
You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional.
The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
Re: Java 8’s new Optional type doesn't solve anything
#3Static analysis is great, but excessive annotations are not fun.
In my (admittedly limited) experience, people omit them, forget to update them, and then rely on the analyser to magically catch everything.
Sure, library solutions like Optional can always be misused, but there's no silver bullet to negligence.
Re: Java 8’s new Optional type doesn't solve anything
#4TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional. The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException.
The only value Optional has over regular values is that the developer has to assume the value can be missing - but the same was true for nullable properties.
Re: Java 8’s new Optional type doesn't solve anything
#5The lack of pattern matching doesn't make it useless. The existence of Optional reminds the programmer to check whether the value is present, and the type system does enforce this; you can't accidentally treat an Optional as a reference of the same type. The type system does help us remember to handle things; it is a reminder enforced by the type system that's easy to examine during code review.
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.
Re: Java 8’s new Optional type doesn't solve anything
#6TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional. The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException. The only value O…
At least one of the values of Optional is to communicate in the API that a value can be missing. The article mentions that:
A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario."
Making this clear to users of an API is something that nullable properties can not do. The user has to deliberately ignore the fact that the value might be missing by calling `.get()`.
This looks like a advantage to me, so to say that Option does not solve ANYTHING seems incorrect. It certainly does not solve EVERYTHING.
Re: Java 8’s new Optional type doesn't solve anything
#7TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional. The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException. The only value O…
> Optional myOptional = null
That hasn't been a problem for me in practice. It's pretty clear that a reference to Optional should never be null. It can be statically or dynamically checked with @Nonnull or a precondition.
> but the same was true for nullable properties.
It's inconvenient to have to treat everything as possibly null. It's a lot nicer to create the convention, within one's codebase, that references are always nonnull and only Optional are nullable.
Re: Java 8’s new Optional type doesn't solve anything
#8TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional. The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
Definitely. For me, the main use case of Optional is to provide a way for programmers to express the semantic fact that "there is no such object" without resorting to null.
Doing this leads to checking if (obj == null) for dealing with the semantic case that the object is not present, but other kinds of failure may cause obj to be null, but should be treated differently (for being a lower-level issue, for example).
So, Optional is basically a way to differentiate between different types of nullity.
Re: Java 8’s new Optional type doesn't solve anything
#9TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional. The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...
The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException. The only value O…
Right, but the difference in reality is that developers don't check every reference to see if it's null. The difference between a raw reference and optional is that with optional the author of the interface has explicitly signalled 'you really ought to check this'. Optional provides the ability to work with better conventions.
Sure, this doesn't live up to the actual guarantees provided by other languages, but that's not the same as being useless.
Re: Java 8’s new Optional type doesn't solve anything
#10I think the main use of Optional is in a codebase which doesn't _ever_ allow "null".
If every method call either returns an actual object then you can get rid of null checks, and not bother doing any checks on method returns that don't return an Optional.