Optional - The Mother of All Bikesheds by Stuart Marks

Subscribe to Devoxx on KZbin @ bit.ly/devoxx-youtube
Like Devoxx on Facebook @ / devoxxcom
Follow Devoxx on Twitter @ / devoxx
The Optional class was introduced in Java 8 in order to solve a narrow but frequently occurring problem: what to return if you have nothing to return. It is a single class with less than 20 methods, but it turns out to have been one of the most controversial and most misunderstood APIs, having generated several "centithreads" of discussion on OpenJDK mailing lists. Indeed, Brian Goetz (Oracle's Java Language and Libraries Architect) has mentioned that one aspect of Optional was his biggest mistake in Java 8. Optional is also one of the more widely misused APIs. A brief survey of OpenJDK code revealed several embarrassing examples of Optional usage, and expert Java programmers have admitted to not making the most of this API.
This session covers the history and rationale of Optional, provides recommendations and examples of proper and effective usage, shows several antipatterns and code smells and how to fix them, and finally describes some current and proposed work on Optional for Java 9.
Stuart Marks is a Principal Member of Technical Staff in the Java Platform Group at Oracle. He is currently working on a variety of JDK core libraries projects, including Collections, Lambda, and Streams, as well as improving test quality and performance. As his alter ego "Dr Deprecator" he also works on the Java SE deprecation mechanism. He has previously worked on JavaFX and Java ME at Sun Microsystems. He has over twenty years of software platform product development experience in the areas of window systems, interactive graphics, and mobile and embedded systems. Stuart holds a Master's degree in Computer Science and a Bachelor's degree in Electrical Engineering from Stanford University.
[VXM-7030]

[@jianwuchen]

From my discovery, Optional is one of the most misunderstood and misused API among Java/Scala developers. I saw many articles mislead people that Optional is a supreme of null, so people should avoid null as much as possible. That leads to lots of convoluted code because of the abuse of optional. This video gives the best explanations on the purpose of Optional and when to use or not to use it. Thanks for the insightful talk.

[@gJonii]

To be fair, pretty much anything and everything is superior to using null, it's just that some stuff is not that much better. Existence of null is not considered a billion dollar mistake for nothing.

[@lisafox9026]

At LAST !! i understend how Optional works!!! Thanks

[@ZacharyBetz]

One of better videos on Optional I've seen. Thank you

[@glaurung9791]

Kotlin took care of the mistakes that come from optional by forcing you at compile time to deal with nullability upfront when you define any instance. If you're a java developer that hasn't started using Kotlin you're in for a lot of fun.

[@bhaaratsharma6023]

The best talk on Optional on KZbin

[@old_conrad]

Excellent video. Recently at work some upgrades are happening which have pushed Optionals up the priority chain for improving how we work. However, I was suspicious about how they were being used, but now I have a better understanding why, and can already assist in stopping some bad habits forming. Thumbs up!

[@shanphreak]

just saw a few minutes that someone pointed me to and I couldn't agree more with what he said. Clever programming is not always good, its a maintenance nightmare.

[@-morrow]

29:00 I disagree here. E.g. Flatmapping Optionals allows for much cleaner code than having multiple nested if-not-null checks.

[@hellowill]

why doesnt optional extend collection, given its a collection of size 0 or 1

[@KhanSlayer]

These guys should do more talks like this. If they gave this kind of talk before releasing Checked Exceptions the world would have been a better place. A lot of the new JDK concepts are foreign to java and will be misused and lead to terrible code if standards aren't well articulated.

[@SourabhBhat]

This talk actually answered a lot of questions that I was struggling with. Thank you. But I am unable to find the @Nullable annotation in standard Java! When I use @Nullable , NetBeans imports "com.sun.istack.internal.Nullable" ! What to do about that?

[@bigkahunauk1]

It's part of JSR-308. If you use IntelliJ, JetBrains have their own library which allows the IDE to check for null conditions with appropriate annotation at compile time. There's also a static analysis library called the Checker Framework which is an implementation of JSR-308 which does the same thing. There are also more annotations to use in that library.

[@SourabhBhat]

Thank you !!

[@kennethcarvalho3684]

Is it possible to replace two ifs with an optional.. Like if a! = xx and b! = yy then do something. With optional of nullable

[@pmcgee003]

Optional of optional is the basis of a monad, which optional is / should be.

[@mahmudakbarpur6922]

In given example with customerIDList, the given code is not compiled: The commented out l2 ines, that can't be compiled, because the both methods isPresent() and get() are NOT static. I added the filter to .filter(c -> c!=null) and it works, as the below code: List customerList = customerIDList.stream() .map(Customer::findByID) .filter(c -> c != null) // .filter(Optional::isPresent) // .map(Optional::get) .collect(Collectors.toList()); Can somebody confirm/decline my chnages? I wold appreciate any help.

[@th07h]

where is that slide that is addressing why not to use Optional for fields? did i miss something? there is a rule to not use it for fields, but did not catch when it was discussed (anyone got a timestamp for that?)

[@sebastian_tec]

is in the minute 42:47

[@sebastian_tec]

again at minute 55:29

[@ahmadjaber2940]

I still don't understand what is the winning of doing if (object.isPresent() )instead of checking if the value is null by doing if (object==null).

[@LucaMolteni84]

Hi Ahmad. By using the optional in the API of your program the fact that the value can be missing is explicit. The fact that the reference could be null is written in the type itself. Every reference could be null in Java but we don't check for != null every item. Hope it helps

[@richardwild76]

There is none, and if you watch the video he makes exactly that point and explains how to use Optional better than that.

[@imperatoer]

Using `Optional` and `get()` is almost always a code smell: leanjava.co/2018/02/01/optional-get-is-code-smell/

[@mesarvagya777]

Concept of Optional in Java comes from Maybe of Haskell. In the end its all about composition. Consider reading this article www.oracle.com/technetwork/articles/java/java8-optional-2175753.html

[@yandryperez7451]

Such a likeable guy

[@pmcgee003]

They showed a valid or default method. The final add example is pretty much ( opt1.orelse(0) + opt2.orelse(0) ), Inside an optional.

[@jorsol]

2:46 Rule #1 should be: Optional will never be null, ever. I wonder why not a little java compiler magic to transform this: Optional name = null; to this?: Optional name = Optional.empty(); Or any combination that assigns null to an Optional (more or less like autoboxing), making Optional fully null-free.

[@nirvananevermind3307]

said it yourself, "little java compiler magic"

[@AndiRadyKurniawan]

I think it's wrong to declare an Optional variable and initialize it with null value in the first place.

[@jorsol]

@@AndiRadyKurniawan yes, it's absolutely wrong, but it's possible and error prone, so why not a little help of the compiler to avoid that?

[@tankostream]

1 hour for Optional, you gotta be kidding me

[@tohopes]

Watching the whole presentation was Optional, you know.

[@samsoftx]

lol... pun intended

[@FrenchPirate83]

You'd be surprised. So many people misuse Optional...

[@benzflynn]

But it took them YEARS to introduce this method of handling null values . . . You expect these boys to make it all look simple, Kek ? Oh, you are most insensitive to those hard-working developers at Oracle ! I'm so upset about it, boo-hoo-hoo!

[@ivanpolovyi4427]

Cool

[@martinvysny6514]

The customerNameByID() function can be written in Kotlin as follows: fun customerNameByID(custList: List, int custId) = custList.firstOrNull { it.id == custId } ?.name ?: "UNKNOWN" More concise, less theory, more fun. I jumped the Java ship and not looking back. I just have hard time understanding why someone would want to complicate his code with Optional methods.

[@martinvysny6514]

Also, at 24:30, Java is generally sacrificing code readability to have nulls caught by the compiler. That is ridiculous - Java always sacrificed features for readability. Now it's sacrificing readability for ... what? Optional and stream just feels so heavy. Java Enterprise at its finest :-(

[@ebuzertahakanat1082]

sacrificing for most frequent exception NPE which not readable as exception. now it is less exception and when it does it is meaningfull.

[@donwald3436]

Yes it'd be nice to have elvis in Java.

[@joaoserrano312]

@@martinvysny6514 I believe streams/lambdas/optionals increase readability and reduce code once you get used to using it well : ) Ofc we gotta learn another new thing (and complicated at a 1st glance) but it's worth in the long run. In my company, we're reducing some methods to half code and double solidity . Stuart gives a lot of insight into why Optionals can do the above. Give it a try ( :

[@nikhilagrawal8888]

My feedback - lecture is mostly theoretical rather than hands-on as I see in venkat video lectures which are more practical. It would be great if he opens his IDE and runs his code.

[@AN-us2en]

is it hard to put link on slides in description?

[@nitinagrawal6637]

Check - www.nitinagrawal.com/code-snippets.html

[@heltengundersen]

Couldn't watch the whole video. I'm terrified that members of Technicall Staff in the Java Platform Group is *this* unaware and hostile of the Maybe monad. Has absolutely no clue about functors, the join function and similar. He says that he can't understand what use an Optional could have (given that the join function is THE BASIS of a monad). Seriously, I cringe when watching this.

[@tamilshoutcom]

Been to Devoxx and JAX talks for years now. Costs around £500 for a 2 day talk event excluding any hands on workshops. Absolute horse shit talks and stuff you could learn on KZbin in about 10 mins dragged on for an hour or more. This talk is one such perfect example. It amazes me that some individuals actually pays and attends this crap. You do make some cool friends from across companies and might get better exposures and opportunities if that's what you are going for. Well for me it is company sponsored and I take it more like a couple of days off from work and an outing to hang out with friends.

[@dirkpludwig]

Just one question: With all the problems regarding the (mis)use of Optional that you presented here, don't you personally wish that you never had added it to the API? For sure there would have been several options, avoiding this Optional mess. The most obvious is to simply throw a dedicated exception when processing data in a stream pipeline that yields "no result". The other would have been to pass a closure to those stream operations that may produce an empty result (e.g. filter or map), giving instructions on how to handle the "no result" case. What you did (well, maybe not personally you), is to screw up the a whole API for a single use case of using streaming pipelines. If I did that on my customer projects, I would get fired. You guys at Oracle just live in an ivory tower, that has nothing to do with reality. Sorry that I have to say this, it's just my personal opinion. But I see the same thing happening with forthcoming Java versions, especially with project Jigsaw.

[@PaulenePurdy]

This presentation is way too long. Tell me what benefit Optional really gives and give me examples of how to use it. Why is it better than null? 36 minutes in and I feel like he has kept repeating himself and not made his case.

[@nikitamyazin6586]

TL;DR This is the way to use built-in type system to check your code instead of doing it manually. Which, in fact, is its main task. Suppose you want to write a method that takes an User, accesses the user name then passes it to an external service then transforms response then returns the result. In that case, you should do the follows: 1) Check whether the user is not null 2) Take user name 3) Check that the user name is not null 4) Pass it to other service and store the response 5) Check that this response is not null 6) Transform response to a final result 7) Return the result We have 7 steps, one of which is pretty common (return the result), 3 of which are business logic and 3 of which are null check for safety. Overall, roughly half of our action is required only to prevent NPE. Which is no surprise because before any action with any object, you must check that it is not null. Of course nobody will ever do such insane amount of checks. Almost every programmer thinks that he is smart enough to know which things will never be null. Even if the programmer indeed that smart and didn't made a mistake, some other change later on can easily break it. There are some tools that will notice these changes, but they are not build-in, therefore not every project will use them. Which means we have no mechanish to prevent such situations. If you are using null, there is just no way to tell the compiler `okay this should _never_ be null` nor `okay, this method can return null, please make sure that whoever uses the result will check it before calling any method on it`. Which means compiler can't help us with this and we are on our own. But you do have such mechanism with Optional. You can explicitly say which things can be absent, and which things should always exist. You can't forget to check whether the value exists or not, because your code will not compile, as it was with null. You don't have to keep in mind the whole project and think what places you could have break when you retured null instead of real value. The compiler will do all of that for you. For example, in Scala, using null is considered to be a bad practice. For over a year of production expecrience in Scala, the only few NPE we faced is when we used Java API and forgot to wrap it into Option (in Scala, Optional is called Option). I understand the concern that Optional will consume extra memory as well as affect performance. But I doubt that most Java projects are so fast and care about performance that much that the usage of Optional will lead to a noticeable slowdown. In the end, you can always use an Optional as a safer approach, and switch to null where it really matters. I hope this will give some understandig of why Optional is better than null.

[@donwald3436]

This guy is way too full of himself.

[@HerbertLandei]

I met him at the JCrete 2016, and he is not.

[@Sethorion99]

How so?