Java 8’s new Optional type doesn't solve anything

The 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.

Adding my voice to the din of people noting how far afield of the point the author is:

You should almost never call .get(), except in cases where the code path does not allow an empty optional.

Even so, calling .get() on an empty optional is better than handing nulls around. A null may -- by chance, really -- make it several lines down the code, so that the stack trace points you much later in the code than where the null originated. Calling .get() on an empty optional immediately throws a NoSuchElementException, pointing you directly to the line where the optional was empty where it shouldn't have been.

Consider this code:

    User user = getUser();
    // other stuff here
    // ...
    // ...
    String userSummary = formatUserSummary(user);
    // ...
    // ...

where

    public String formatUserSummary(User user){
        return "Franchise Location: " + 
            user.getFranchise().getLocation().getName() + 
            " Username: " + 
            user.getUsername();   
    }

An NPE occurs inside of formatUserSummary. Where did the null come from? Is the user's Franchise null? Maybe the Franchise's Location? Or is it the User that's null?

If you instead took an Optional<User>, even if you just immediately unwrapped it with .get(), you'd at least get an error that unambiguously told you that it was the user that was missing.

The author is missing the point. The fact that Optional can result in a nullpointer doesn't mean you should use in the same manner as null-checks.

You shouldn't replace:

  if(x == null)
  {
    y = x.doSomething();
  }

with

  if(optionalX.isPresent())
  {
    y = x.doSomething();
  }

You should replace it with:

  y = Optional.ofNullable(x)
    .map(ClassX::doSomething)
    .orElse(null);

I've been using Swift for over a year now, which has had an Optional implementation from day one. I see a lot of people defending Java's implementation in this thread, can someone check my understanding? I did Java in a past life but am not super familiar with Java 8.

In Swift, types are non-optional by default. You can never end up with a null, the compiler makes it impossible. Optionals are out of the way until you need them, and if you use them properly (i.e. avoid the .get() equivalent), it's still impossible to crash from a null.

In Java 8, things can still contain null by default and you might not know about it, right? You can express that something is Optional in your API, but that's only marginally better than documentation, doesn't solve "unexpected nulls" whatsoever, and makes this only halfway to a solution and therefore broken entirely. Why not just use annotations?

Are my assumptions and understanding correct?

I've only used the Guava version of Optional, which appears to have a slightly different API than Java 8's. (You can tell there's a Java 8 committee, that's for sure.)

The biggest problem I found in applying Optional is that Optional is very much a Haskell-y concept to me, and Java programmers and Haskell programmers don't really overlap much. Therefore, to me, Optional is just a functor like a list or a set. So doing Optional.asSet() and iterating over the result is, to me, the correct way way of handling an optional value. If there's something in there, the loop runs once. If there's not anything in there, the loop runs zero times. This is exactly like "fmap" in Haskell:

  Prelude Data.Functor> fmap (+1) $ Just 42
  Just 43
  Prelude Data.Functor> fmap (+1) $ Nothing
  Nothing

(Except that Haskell automatically preserves the type safety, whereas you have to re-wrap the value if you're using Java. Functional programming in Java never works, and this where the Optional idea starts to go wrong.)

But I got "I don't really understand this" in code reviews every time I did that; the Java way is to check if it's set, then do a type-unsafe unboxing. Thus, like the article said, completely defeating the purpose of the Optional type.

That said, it's pretty rare to need exactly 0 or 1 of something. If you're doing a database query, you can probably make the API return a set of rows. Then it's natural to loop over the results and nobody raises their eyebrows.

Brian Goetz's response: "They didn't solve the problem I thought they should have solved, so their solution is worthless." Thank you, internetz.[0]

In any case, that's not what Java's optional is there for[1]. Solving the safety problem is the job of Java 8's pluggable type systems[2] that are both more powerful than the static-analysis tools listed in the article and had Oracle's official support (in the form of JSR-308).

[0]: https://twitter.com/BrianGoetz/status/656860771196887040

[1]: http://stackoverflow.com/a/26328555/750563

[2]: http://types.cs.washington.edu/checker-framework/current/che...

TL;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...

I don't program much Java, but how expensive are exceptions? Wouldn't it make more sense to expect functions that could return null to instead throw a checked exception if something goes wrong?

eg

     public dbResult doDatabaseThing(stuff) throws DatabaseException
  

So if you do

     result = doDatabaseThing(stuff)
  

the compiler will require you to do something about the DatabaseException.

It seems to me that the point of, for example, Option and Result in Rust is to avoid the whole checked exception mess while still passing useful information about things that go wrong. But, given the problems pointed out in this article (lack of pattern matching and algebraic data types mostly), checked exceptions might be a more correct way to do it in Java.

Optional is planned to become a value type in Java 10, so while the current situation is less than perfect I don't consider it a big problem.

Using get() is just bad style and so is returning null where you could return Collections.emptyList().

Previous discussion on reddit: https://www.reddit.com/r/programming/comments/3pl7o0/java_8s...

tl;dr: use map, orElseGet, orElse

Shameless self plug

"Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin"

http://codemonkeyism.com/comparing-optionals-and-null-in-swi...

I 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.

Optional (either JDK or Guava) is not perfect but is infinitely better than hand-checking for null. Among other things, it expresses the intent of the API writer that their method may or may not return an absent value and this is expressed via the type system. This is in stark contrast to using null as a primitive, which has no such transparency. For instance, there is no difference in Java's type system between a method that intends to always return a non-null String, and one that intends to return a null String under certain circumstances. Thus it is impossible for the user of the API to determine when to build conditional logic to check for null or when not to bother.

In any case, the concept of null as a primitive is fundamentally broken. Due to Java's backward compatibility requirements, it's too late to resolve this in that language. However, newer languages don't need to make this mistake. However, there are "interoperability" requirements for new languages interfaces with legacy runtimes that tempt language designers to build escape hatches. These escape hatches exist in Swift, Kotlin, Rust, etc even though they're not recommended and their usage presents edge cases.

Ceylon and Haskell seem to be the only two languages to get this completely right. Ceylon expresses optionality as the union between the present value type and null, which is an actual type separate from Object. An optional String is therefore a String|Null, or a String? Haskell accomplishes this with the Maybe type.

All this to say that null should not be a primitive but should be banished to its own corner of the type system with clear compile-time semantics for dealing with the absence of values.

We tried to use Optional<> instead of returning null. Accidentally returning null from methods returning Optional<> is something that actually happens, especially when migrating existing code. Of course you can solve that with @Nonnull annotations, but then why use Optional in the first place?

The other problem is that the Optional<> interface is clunky. There is ifPresent(), but no ifAbsent(). The stream syntax is incompatible with the rest of the Java world, in the same way that List<T>#toArray has always been ridiculous. And if you use ifPresent(), you have to live with the fact that you cannot return from Java lambdas, and you cannot change any variables or even use non-final variables. I want to scratch my eyes out when I see people allocate one-element arrays on the heap just to work around Java's lambdas.

I don't see the value of Optional<T> if you already have @Nullable.

All of these problems seem trivial to me. The problem with Optional is that it isn't baked into the API, nor can it ever be, so any use of Optional is after the fact, applied only by the application, which means you need to wrap api calls in Optionals manually, which is something that gets real old, real quick.

I don't understand what's wrong with get() method. Swift has built-in null-safety and it has "!" operator. Kotlin has it. Even Haskell has fromJust function which does exactly the same.

May be name "get()" is too short and innocent-looking.

I think in this thread when we talk about "pattern matching" (which _is_ awesome) were caught up with two notions: pattern based destructuring of input and type enforced exhaustiveness checks. Java 8's Optional does give the latter:

> maybeT.map(t -> ...).orElse(...)

The author does make a good point that 'get' is unsafe. I think it was a necessary concession to team members who are learning how to program in this manner.

  public Optional<Long> badIdea() { return null; }

I think the fact that this compiles is all the argument necessary. What java needed was a ThisWillDefinatelyExist<Object>. Not the opposite, but java just can't do that.

Where did this myth that Option types are the "solution" to nullable references come from? That's got it perfectly backwards. The solution to nullable references is to remove them from the language; Option is just a means for languages that have already done this to encode nullability into the type of a value add necessary, as it should be. And people claiming that a language needs pattern matching or it doesn't solve the problem?! It makes me worry that those advocating these ideas are just part of the latest cargo cult and don't really understand the underlying principles or why these are good ideas in the first place.

I thought Optional was mostly for the steam API, and not just general usage?

We've been using Optional<T> a lot in recent years (via Guava). It's useful, and has certainly reduced the number of NPE we've had slip through as it forces the developer to consider nullability up front. Looking forward to migrating to the Java 8 version when we upgrade to that JDK.

One addition that would be useful would be some syntactical sugar to reduce the verbosity of using Optional<T>. But otherwise I'm happy and if you combine with @Nonnull and @Nullable annotations you get the best of both worlds.

some have already commented here that author maybe complains too much (e.g., calling .get() on an Option<T> is a deliberate move, meaning that the developer explicitly took on the risk of that exception. that's very different than implicitly assuming that a regular ref is not null, using it and getting bitten in the ass.). but this one really hurts:

"The last flaw with Java's implementation is a bit ironic — It's possible for the optional reference itself to be null."

ouch.

Implementing a monad like structure without a monadic for loop syntax sugar tends to confuse people. It's hard to picture writing most operations as map or flatmap.

I love Haskell, but the existence of a bottom type throws all run time guarantees out the window.

    import Control.Monad
    ex1 = Just 1 :: Maybe Int
    ex2 = undefined :: Maybe Int
    inc = liftM (+1)
    main = do
      putStrLn . show $ inc ex1
      putStrLn . show $ inc ex2

Yes, you should never use `undefined`. Now replace `undefined` with `null` and it becomes apparent that Maybe and Optional have exactly the same amount of power.

It's not a get out of jail free card no, but it's value isn't in preventing null pointers. The value of Optional is in providing intent.

You also get map, filter, flatMap, orElse, orElseGet, ifPresent. These are all great ways of making your code more functional, and do more with less.

I don't think annotations are the answer either, as you can't always rely on static analysis to prevent errors, a lot will still appear at runtime.

Would be handy if I could filter out all medium.com entries from the front page for me. Never read anything mildly researched or balanced there...

This remind me of a old say:

"What is worse than not given anything to somebody that need it? Give to him something broken".

Static 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.

I really wished C# would support Nullable for reference types too. This + the new traversal operator (?. ) would be a great combo to get rid of NullReferenceExceptions.

To me Optional<T> without pattern matching seems crap.

I have the same feeling about boost's optional. It's a bandage on a wooden leg.