Java 9 Additions To Optional

Wow, people were really interested in Java 9’s additions to the Stream API. Want some more? Let’s look at …



This one requires no explanation:

Finally we get from Optional to Stream!

The first word that comes to mind is: finally! Finally can we easily get from a stream of optionals to a stream of present values!

Given a method Optional<Customer> findCustomer(String customerId) we had to do something like this:

Or this:

We could of course push that into a utility method (which I hope you did) but it was still not optimal.

Now, it would’ve been interesting to have Optional actually implement Stream but

  1. it doesn’t look like it has been considered when Optional was designed, and
  2. that ship has sailed since streams are lazy and Optional is not.

So the only option left was to add a method that returns a stream of either zero or one element(s). With that we again have two options to achieve the desired outcome:

It’s hard to say which I like better – both have upsides and downsides – but that’s a discussion for another post. Both look better than what we had to do before.

We can now operate lazily on Optional.

Another small detail: If we want to, we can now more easily move from eager operations on Optional to lazy operations on Stream.

I think I didn’t have a use case for that yet but it’s good to keep in mind.


Another addition that lets me to think finally! How often have you had an Optional and wanted to express “use this one; unless it is empty, in which case I want to use this other one”? Soon we can do just that:

Say we need some customer’s data, which we usually get from a remote service. But because accessing it is expensive and we’re very clever, we have a local cache instead. Two actually, one on memory and one on disk. (I can see you cringe. Relax, it’s just an example.)

This is our local API for that:

Chaining those calls in Java 8 is verbose (just try it if you don’t believe me). But with Optional::or it becomes a piece of cake:

Isn’t that cool?! How did we even live without it? Barely, I can tell you. Just barely.


This last one, I am less happy with:

You can use it to cover both branches of an isPresent-if:

Where logLogin is overloaded and also takes a customer, whose login is then logged. Similarly logUnknownLogin logs the ID of the unknown customer.

Now, why wouldn’t I like it? Because it forces me to do both at once and keeps me from chaining any further. I would have preferred this by a large margin:

The case above would look similar but better:

First of all, I find that more readable. Secondly it allows me to just have the ifEmpty branch if I whish to (without cluttering my code with empty lambdas). Lastly, it allows me to chain these calls further. To continue the example from above:

The question that remains is the following: Is adding a return type to a method (in this case to Optional::ifPresent) an incompatible change? Not obviously but I’m currently too lazy to investigate. Do you know?


For some reason only stream and ifPresentOrElse made it to the primitive specializations. And they still don’t have map. What’s going on there? (Thanks to the Pedant for making me put this in here.)


To sum it up:

  • Use Optional::stream to map an Optional to a Stream.
  • Use Optional::or to replace an empty Optional with the result of a call returning another Optional.
  • With Optional::ifPresentOrElse you can do both branches of an isPresent-if.

Very cool!

What do you think? I’m sure someone out there still misses his favorite operation. Tell me about it!

Share & Follow

You liked this post? Then share it with your friends and followers!
And if you like what I'm writing about, why don't you follow me?

Other Posts