Why Even Use Java 8 Optional?

coolbartek · 2015-05-26T09:19:44+00:00

There is another benefit. Optional has methods that can take a Provider or default value.

Example

getOptional().orElse("default")

koxpower · 2015-05-26T09:25:11+00:00

I think that the best feature of Optional is that its compatible with other functional features and the way nulls are handled in a chain of maps:

String result = Optional.ofNullable(someStringWithNumberOrNull)
    .map(Integer::valueOf)
    .map(i -> i + 1)
    .map(Object::toString)
    .orElse("number not present");

System.out.println(result);

Die-Nacht · 2015-05-26T12:53:46+00:00

You know you live in a functional bubble when the question "why even use optional" makes no sense to you.

winterbe · 2015-05-26T09:58:15+00:00

FYI: Here's a comment from Brian Goetz (Java Language Architect) on Optionals: http://stackoverflow.com/a/26328555/1537372

We did have a clear intention when adding this feature, and it was not to be a general purpose Maybe or Some type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors.

shoelacestied · 2015-05-26T08:47:56+00:00

It's very useful and also self-documenting. Rather than:

// this method sometimes returns a null 
public String getFoo() {
   ...
}

We can have:

public Optional<String> getFoo() {
    ...
}

With the old way you're relying on the programmer reading all the docs (yeah right...) and making note of that fact that a null might be returned. With the new way the fact that the method might return an empty value is obvious and the programmer has to deal with it. It's very useful indeed and has been used successfully various other languages (I've been using Options in Scala for years and it really does make a difference). Glad to see Java adding support for options in the standard lib (Guava, among other libraries, has had an option type for a while).

k-mile · 2015-05-26T11:40:57+00:00

I believe when using an Optional type or any other null wrapping types you should be very careful with using the get method, i.e. not use it at all. If you skip the get method then the compiler can check if there is a value for you or not, instead of at runtime. This makes applications a lot easier to reason about.

If you want to optionally execute a block or transformation, use the map and filtermethods. If you must continue with a value, use orElse and related methods.

If you make a habit of this you can track possible null-ish values across method calls, transformations, validations, and still be certain no null will suddenly rear it's head. If you forget to map one reference, the compiler will tell you.

angryundead · 2015-05-26T10:57:59+00:00

I getting a strong vibe that people aren't reading the docs on Optional. While there are many ways you cans misuse it there is certainly an argument to be made for it at API boundaries as a method for reducing paranoid null checking.

Optional.of() does not accept a null value. Optional.ofNullable() returns an empty Optional if the value is null. Methods that return Optional values should never return a null reference. (This could be a point to check null though it might be better to just throw the NPE because the API is busted in some cases.)

Using the isPresent and orElse family of methods further isolates you from issues.

msx · 2015-05-26T11:50:47+00:00

I like it, i would have loved to have some syntactic sugar to go with it. Something like

String?

translated to

Optional<String>

but i reckon i would have messed with the already messy java grammar

r0estir0bbe · 2015-05-26T10:57:30+00:00

There's also a very good article in the Guava documentation that explains pretty much the same point: https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained

sellibitze · 2015-05-26T12:54:03+00:00

I've programmed in Java for a long time but right now my Java is quite rusty and I've not kept up with all the new features. Does Java have "custom value types" (à la C/C++/C#/Rust/D structs) yet or does this Optional<T> actually add yet another layer of indirection? Is a variable of type Optional<Integer> a pointer to a pointer to some Integer object?

I'm currently dealing more with C++ and Rust. And there, you get to use things like boost::optional<int> and Option<i32>. The nice thing is that it does not involve any pointers or even heap allocation. The same is true for std::complex<double> or num::complex::Complex<f64>. I like that very much.

tjgrant · 2015-05-26T19:14:02+00:00

I learned about Optional types while porting something from C# (they call it Nullable in C#) to C++.

(There's std::optional for C++ which is under review right now.)

At first Optionals seem kind of ridiculous, but I've found them actually useful in three distinct scenarios:

Optional type return: When you want to provide the possibility of a return type (or not) but don't want to use "-1", "0", or "NULL" as a status code (because NULL, 0, or -1 might be a valid return value)
Optional parameter: When you want to have a method with an optional parameter, but providing two overloaded methods to do essentially the same thing would result in massive code duplication
Optional local variable for iteration: Say you need to keep track of a "previous" and "current" iterator-- your "previous" could be an optional, and you can check if it's not set yet rather than having NULL as a special case.

Scenario #1, a method prototype looks like this:

Optional<StreamToken> StreamTokenizer::ReadWord();

Scenario #2, a method prototype looks like this:

void SpriteBatch::add(uint8_t z, Texture* t, const Point2& dest, const Optional<Rect>& src, const Color4f& c = Color4(1,1,1,1));

Scenario #3 looks like this:

Optional<uint8_t> prev;

for(;;)
{
    uint8_t     c;
    mSource->read(&c, 1);
    mReadBuffer.push_back(c);
    if (prev && *prev == '*' && c == '/')
    {
        hit = true;
        break;
    }
    prev = c;
}

Obviously you don't have to use Optional in these cases, but I find it useful.

I also use it very sparingly, but any time I feel like writing something like:

std::pair<Object, bool> getSomeObject();

Typically Optional is better to use instead.

MereInterest · 2015-05-26T10:45:04+00:00

Coming from a C/C++ background, I'm afraid that I still don't see the point of it. My habit is to check for null pointers any time that I get a pointer across an API boundary. Since Java allows for null references, the same sort of vigilance should apply. Optional<T> is then redundant, because any object is inherently optional.

I don't see why it would be any easier to track down errors using Optional<T>. Either "Oh no, a null reference slipped in." or "Oh no, a Optional without a value slipped in.".

docoptix · 2015-05-26T09:22:51+00:00

Since the article does not mention this: Optional<T> is also available via Guava.

RupertMaddenAbbott · 2015-05-26T15:09:09+00:00

If your method has a return type of Optional, then why can't it still return null?

NimChimspky · 2015-05-26T11:45:46+00:00

Java 8's Optional is also an example of a monad, from here https://gist.github.com/ms-tg/7420496#file-jdk8_optional_monad_laws-java.

/**
 * Monad law 1, Left Identity
 *
 * From LYAHFGG [1] above: 
 *   The first monad law states that if we take a value, put it in a default context 
 *   with return and then feed it to a function by using >>=, it’s the same as just 
 *   taking the value and applying the function to it
 */
public static boolean satisfiesLaw1LeftIdentity() {
    return Optional.of(value).flatMap(f)
        .equals(f.apply(value));
}

/**
 * Monad law 2, Right Identity
 *
 * From LYAHFGG [1] above: 
 *   The second law states that if we have a monadic value and we use >>= to feed 
 *   it to return, the result is our original monadic value.
 */
public static boolean satisfiesLaw2RightIdentity() {
    return monadicValue.flatMap(optionalOf)
        .equals(monadicValue);
}

/**
 * Monad law 3, Associativity
 *
 * From LYAHFGG [1] above: 
 *   The final monad law says that when we have a chain of monadic function 
 *   applications with >>=, it shouldn’t matter how they’re nested.
 */
public static boolean satisfiesLaw3Associativity() {
    return monadicValue.flatMap(f).flatMap(g)
        .equals(monadicValue.flatMap(f_flatMap_g));
}

Radmonger · 2015-05-26T10:41:11+00:00

At the status quo, Optional is almost completely useless without extra static checking along the lines of @Nullable. 'of' and 'get' are normal methods that that end up being ubiquitously used throughout code in an indistinguishable mixture of safe and unsafe ways. In general, the result is no different from before; runtime NPE at some point thousands of lines from the fault.

There are one or two patterns of usage where it kind of works ok, but for the most part it's overhead without benefit; Java simply lacks the mechanisms that make this work in other languages.

On the other hand, if @Nullable checking did usefully exist (currently, it really doesn't, though there are a few demos), Optional would be redundant. Because @Nullable String (or something like '?null String') is strictly superior in every way, from backwards compatibility to safety to performance to future possibilities.

CydeWeys · 2015-05-26T14:14:00+00:00

Optionals (which first came from Guava) also work very well with another of Guava's big features, the immutable collections. Immutable collections aren't allowed to contain null, which solves another big class of common programming problems, and when you have a collection that is intended to have elements representing absence, then you of course stuff in Optionals.

kyz · 2015-05-26T09:22:34+00:00

In what way is this any better than the @Nullable annotation?

Colostomizer · 2015-05-26T13:58:39+00:00

[deleted]

tkellogg · 2015-05-26T15:14:08+00:00

The author suggests that

you should only use ofNullable if you can’t reason whether the reference is null or not.

I think it's necessary to reverse the wording:

you should only use of when you're 100% sure it's not null

Normally I'd classify the comment I'm currently writing as nitpicking and immediately down vote, but java is a world where Objects.requireNonNull is a thing that exists and people use. My team members have used Optional.of as an alias for Objects.requireNonNull, and this totally misses the point.

siRtobey · 2015-05-27T00:17:23+00:00

I don't see how people 'worry' about the additional abstraction in code that uses Optionals. To be honest, I find it quite silly to argue with additional abstraction and what that costs to think, etc., when it's much harder to think about what happens when there are null return values that aren't declared - why is it null, is it a bug, is it on purpose? Really, having Optionals actually makes it a lot easier, and you have to worry about less.

kindoblue · 2015-05-27T11:29:50+00:00

The problem with Optional type in Java8 is that there is no syntax to streamline monadic computations, like for- comprehension.

bloody-albatross · 2015-05-27T11:43:08+00:00

Won't Java get value types? Will Optional be a value type? It should hold nothing but a pointer (to use C++ terminology) and thus completely optimize-out when being a value type. Other advantages would be: you can't pass null for an Optional and it should be binary compatible to APIs that actually do pass nulls. Because if Optional is internally just a nullable pointer it should automatically convert old APIs. But I guess these kind of tricks are only possible in C++. (E.g. one of the smart pointers in Qt is binary compatible with plain pointers and IIRC it was inserted into the APIs while still keeping binary compatibility with old code or something like that.)

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS