I thought Optional was mostly for the steam API, and not just general usage?
Java 8’s new Optional type doesn't solve anything
61–70 of 197 posts
Re: Java 8’s new Optional type doesn't solve anything
#62I'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
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.
Re: Java 8’s new Optional type doesn't solve anything
#63I have the same feeling about boost's optional. It's a bandage on a wooden leg.
std::string always is a value, boost::optional isn't (similar to std::string, just a lot safer).
The problem is that Java only has boost::optional, which can be null, empty or a value.
Re: Java 8’s new Optional type doesn't solve anything
#64I have the same feeling about boost's optional. It's a bandage on a wooden leg.
But is it really? Maybe I'm missing the point but it is a nice way to express that a function may or may not calculate something, no? At least it seems way better than returning bare pointers or pasing an argument by reference+returning bool, or returning a unique_ptr, or ...
If you come from ML or Haskell and start using boost or Java's option, you actually feel ripped off.
Some people claim it's a sort of documentation denoting 'intent', but I don't want documentation. I don't want options to infect the whole codebase, I just want to pattern match once and extract the value, and never have to check again for None or null.
The problem in Java is the type system has references. X static use_it(X x){ ....}
really has a signature something like this: use_it : X ref -> X ref
no little library is going to fix that.
Re: Java 8’s new Optional type doesn't solve anything
#65All 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.
Re: Java 8’s new Optional type doesn't solve anything
#66Earlier quoted context omitted.
The author is missing the point. Is he? The point is that in Java you are still able to treat x unsafely, while languages with stronger typing do not. E.g. in Haskell, if a function returns a Maybe a , it will always be a Just a or Nothing value. Moreover, such languages allow you to make non-exhaustive matching against all constructors a compiler error. tl;dr: Haskell, Rust, et al. put the burden on the compiler. Ja…
>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…
I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.
Re: Java 8’s new Optional type doesn't solve anything
#67I thought Optional was mostly for the steam API, and not just general usage?
Also, despite it not being "standard" @NotNull, and @Nullable have worked really well for me so far. And I don't think Optional was meant to replace them.
Re: Java 8’s new Optional type doesn't solve anything
#68I'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 doin…
> That said, it's pretty rare to need exactly 0 or 1 of something.
That's interesting and sort of hard to agree with. I think uniqueness is very often desirable and very often paired with a lack of certainty about existence.
"Does a user with this identity exist?" certain is handled properly as a 0-or-1 question, e.g..
Re: Java 8’s new Optional type doesn't solve anything
#69We 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#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 if you already have @Nullable.
Re: Java 8’s new Optional type doesn't solve anything
#70The 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 ge…
Exactly, it forces the programmer to think about whether something can be null or not and actually had a behavioural change in my java coding.
Wouldn't it be better to have a non-nullable type, akin to C++'s return by value? That way, instead of forcing the programmer to think, you are removing the problem that they would need to think about.