Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8’s new Optional type doesn't solve anything

medium.com

Post reply on HN
Print view View original

121–130 of 197 posts

Re: Java 8’s new Optional type doesn't solve anything

#121

Post by peeters »

bkv wrote: post #89
jcrites wrote: post #5

The 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…

>Yes, you can write get() and risk an exception. So don't do that. Yes, you can dereference a null pointer and risk an exception. So don't do that. See where this is going? The problem with Java's optional is that it is by all appearances (in name and high-level description), a general purpose optional, albeit with a ton of gotchas that will result in people saying "Just don't do that." Java's optional is not a gener…

>>Yes, you can write get() and risk an exception. So don't do that.

>Yes, you can dereference a null pointer and risk an exception. So don't do that.

Except these aren't at all the same. With a reference, you have no good way of telling whether your reference IS nullable. With Optional, it's ALWAYS optional.

Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks.

Sure pattern decomposition is nicer, but that doesn't mean that Java's implementation "defeats the purpose entirely" like the author suggests. I'd love everything to be checked statically, but if that can't be done, I still like strong conventions which make the code clearer and safer.

Re: Java 8’s new Optional type doesn't solve anything

#122

Post by Gankro »

valarauca1 wrote: post #113
Gankro wrote: post #93

Earlier quoted context omitted.

This seems a bit too unpragmatic. Would you also require the user to explicitly handle: * Index out of bounds on every array op * Integer overflow on every arithmetic op * OOM on every allocating op Maybe if you're writing an ironclad RTOS for a critical system without any good redundancy? Otherwise these are such pervasive operations that most have accepted that they're not worth handling everywhere they happen. Req…

>Requiring that really dilutes the value/meaning of errors. No. You have already diluted the meaning of errors, and you want them elevated to _your_ standard. >Index out of bounds on every array op These are removed if you build a rust program with --release. >Integer overflow on every arithmetic op Add the Wrapping class if you expect overflow. Overflow _shouldnt_ normally happen on an Integer operation. It is a har…

What have I diluted the meaning of errors to?

Rust doesn't remove bounds checks in --release. It's wrapping that gets turned on in release. I'm not sure why you're distinguishing overflow as truly exceptional, as opposed to any other "this should never happen" error?

Also I don't think many C libraries that allocate expose that as a failure condition (I've certainly seen some which don't even check!)

Re: Java 8’s new Optional type doesn't solve anything

#123

Post by RHSeeger »

gurkendoktor wrote: post #60
jcrites wrote: post #7

Earlier quoted context omitted.

> Optional myOptional = null That hasn't been a problem for me in practice. It's pretty clear that a reference to Optional should never be null. It can be statically or dynamically checked with @Nonnull or a precondition. > but the same was true for nullable properties. It's inconvenient to have to treat everything as possibly null. It's a lot nicer to create the convention, within one's codebase, that references are…

> That hasn't been a problem for me in practice. It has for me. Functions have multiple return points, some of them returning "null". Lead developer insists we use Optional to clarify that these functions can return null. People go over the function, replacing each instance of "return null" with "return Optional.empty()", but forget some instances. Now we have Optionals that are sometimes null.

But that's a bug in the library (or code you're calling into), not a bug in how you're using it. That's the main difference in my opinion.

Optional allows the code to say "I never intend to return null, only an Optional that may be nothing". In theory, a library/module/whatever that's been converted to use Optional should not have any calls that do return null.

In theory, its no different than a C API that can return a size or -1 for failure. Sure, it could return -2 because the language allows it, but you shouldn't need to check for that in your code that uses it.

Re: Java 8’s new Optional type doesn't solve anything

#124

Post by the_af »

pandler wrote: post #42
jontro wrote: post #19

Earlier quoted context omitted.

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.

> Exactly, it forces the programmer to think It's a curious feature, the way you've described it. I have virtually no experience with Java so I'm looking at this from a totally foreign perspective. The authors considers it an ineffective feature because you still have to think about null checks, whereas you consider it an effective feature because it forces you to think about the problem instead of ignoring it.

No, the author considers it ineffective because you are not forced to think about nulls at compile time. Of course, at run time they will explode in your face, so you still have to consider them eventually.

@jontro is saying that proper Optionals make it impossible (or at least, more difficult) to forget about the problem at compile time.

Re: Java 8’s new Optional type doesn't solve anything

#125

Post by aclissold »

Lewton wrote: post #114
aclissold wrote: post #111

I've been using Swift for over a year now, which has had an Optional implementation from day one. I see a lot of people defending Java's implementation in this thread, can someone check my understanding? I did Java in a past life but am not super familiar with Java 8. In Swift, types are non-optional by default. You can never end up with a null, the compiler makes it impossible. Optionals are out of the way until you…

I don't think anyone thinks that Optional as it is in Java right now is the perfect solution. The article seems to be making the case that Optional isn't an improvement of what came before, which is what people are having issues with.

Ah. Right! "doesn't solve anything" is definitely not the case:)

Re: Java 8’s new Optional type doesn't solve anything

#126

Post by louthy »

vbezhenar wrote: post #78
serpix wrote: post #74

Earlier quoted context omitted.

If you are certain optional has a value, don't use optional. Checking presence of value of an optional is an anti-pattern, the same as doing != null checks. You should treat Optional the same as a List type with size 1. You never check if a list is size 1 before doing map or filter.

I'm not always own code. Simple example: getCharsetOpt("UTF-8") There is no way this code will return None in this particular case. So any additional checks are unnecessary and make code less readable.

I don't know who said it, and this is probably a paraphrase:

"If it can't happen, it will".

If a function says the result is optional, then it's optional. It's not not optional because you decided it can't ever fail.

Re: Java 8’s new Optional type doesn't solve anything

#127

Post by peeters »

Manishearth wrote: post #105
krisdol wrote: post #45

Earlier quoted context omitted.

>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…

> you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. Explicit vs implicit. In Rust/Haskell you are forced to do _something_ about the nullability. If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. On the other hand, in Java, you can get an NPE where you didn't expect it because nulls move around easily…

> If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails.

If you use Optional.get() without Optional.isPresent(), how is that any different? It's not as nice as pattern decomposition, but it's still fundamentally the same, and on top of that, transform functions are provided so that most of the time you can do null-safe operations.

Re: Java 8’s new Optional type doesn't solve anything

#128

Post by kllrnohj »

ucho wrote: post #28
ubertaco wrote: post #24

Adding my voice to the din of people noting how far afield of the point the author is: You should almost never call .get(), except in cases where the code path does not allow an empty optional. Even so, calling .get() on an empty optional is better than handing nulls around. A null may -- by chance, really -- make it several lines down the code, so that the stack trace points you much later in the code than where the…

> Where did the null come from? A bit offtopic but SAP JVM puts that info in NPE error message[1], I don't know why others implementations don't, maybe it is incurring too large overhead? [1] it is something like "Attempted to call getLocation() on Franchise object returned from getFranchise() but it was null"

ART on Android does this as well.

Re: Java 8’s new Optional type doesn't solve anything

#129

Post by rickette »

jcrites wrote: post #5

The 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…

Java 8 Optional is useful (although the API could be better).

If only FindBugs would warn about calling get() without checking isPresent() first. There's an open FindBugs ticket for this: http://sourceforge.net/p/findbugs/feature-requests/302/

Re: Java 8’s new Optional type doesn't solve anything

#130

Post by valarauca1 »

Gankro wrote: post #122
valarauca1 wrote: post #113

Earlier quoted context omitted.

>Requiring that really dilutes the value/meaning of errors. No. You have already diluted the meaning of errors, and you want them elevated to _your_ standard. >Index out of bounds on every array op These are removed if you build a rust program with --release. >Integer overflow on every arithmetic op Add the Wrapping class if you expect overflow. Overflow _shouldnt_ normally happen on an Integer operation. It is a har…

What have I diluted the meaning of errors to? Rust doesn't remove bounds checks in --release. It's wrapping that gets turned on in release. I'm not sure why you're distinguishing overflow as truly exceptional, as opposed to any other "this should never happen" error? Also I don't think many C libraries that allocate expose that as a failure condition (I've certainly seen some which don't even check!)

>Also I don't think many C libraries that allocate expose that as a failure condition (I've certainly seen some which don't even check!)

This is a very common mistake in most C code. Malloc can fail, and it return NULL when it does.

Post reply on HN