Optional - The Mother of All Bikesheds by Stuart Marks

Devoxx0 HN recommenders · 2019–2022
63K views · talk · evergreen · Uploaded 2016-11-11

Stuart Marks explains the intended purpose and proper use of Java 8's Optional class and why it caused so much controversy. He gives guidelines for using its small API correctly.

Cited as the authoritative explanation, from the person who added it to OpenJDK, of Optional's narrow intended purpose.

Watch on YouTube

3 comments from Hacker News

@kjeetgill2019 · in “Takes: Java web framework without static methods or annotations”

That's not really "why" it was introduced. Optional is used as a null wrapper in other JVM languages so that idiom bled over pretty naturally. Here's a talk "Optional - Mother of all Bikesheds" by Stuart Marks, the guy who added it to OpenJDK: [VIDEO] It was mostly just meant to cover the zero or one case on fluent-style interfaces like the Streams API, so check as getFirst() or getAny(). In hindsight, the name Optional was a poor choice if they didn't want the idiom coming over.

@emccue2022 · in “What I miss in Java, the perspective of a Kotlin developer”

These are pretty weak arguments For the first point - val/var "More importantly, it doesn’t offer its immutable counterpart, val. You still need to add the final keyword, which nearly nobody uses." This super undermines the criticism. "It has the feature but people don't use it" isn't exactly much to write home about. Just use `final var` if you want. Make "final var over var" the same force culturally as JS's const over let" "However, the developers of Optional designed it for return values only. Nothing is available in the language syntax for methods parameters and return values. To cope with this, a bunch of libraries provides compile-time annotations:" This flow of causality here is slightly incoherent. The phrasing implies that if there was a version of optional that was designed for method parameters that would be better and there would be less of a need for compile-time annotations. Here it is sealed interface Option<T> { record Some<T>(T value) implements Option<T> {} record None<T>() implements Option<T> {} } This has "better" semantics than Optional for storing in fields and for using as method parameters. The existence of this does not obviate the desire to have null static analysis, so Optional really isn't that related. [VIDEO] It is true though that Kotlin has a more consistent story here, but there are active efforts to improve it for Java. Also, the discussion of extension functions points out that static methods cannot be chained like instance methods - corre

@cratermoon2022 · in “Rust should not have provided `unwrap`”

See also the discussion for a similar feature in Java, from "Optional: The Mother of all Bikesheds", where the use and misuse of get() has a central role. video: [VIDEO] slides: [LINK]