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

41–50 of 197 posts

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

#41

Post by organsnyder »

Latty wrote: post #32
bakhy wrote: post #11

some have already commented here that author maybe complains too much (e.g., calling .get() on an Option is a deliberate move, meaning that the developer explicitly took on the risk of that exception. that's very different than implicitly assuming that a regular ref is not null, using it and getting bitten in the ass.). but this one really hurts: "The last flaw with Java's implementation is a bit ironic — It's possib…

This is another off-base point, in my opinion. Sure, it's possible for it to be null, and that isn't great - but the vast majority of null problems come from the user assuming the interface won't give you a null. Something returning an Optional should never return null, so the ambiguity is resolved. Sure, it still could as a bug, but that's actually a pretty rare case. I don't see it being a real problem.

Exactly. A null Optional reference is such an obvious bug, that it can easily be detected by simple analysis tools. OTOH, a null is often an accepted (if derided) method of indicating that a value simply doesn't exist, so it's much more difficult to detect when a null will cause a problem.

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

#42

Post by pandler »

jontro wrote: post #19
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…

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.

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

#44

Post by pron »

coldtea wrote: post #36
pron wrote: post #34

Earlier quoted context omitted.

As of Java 8, Java has pluggable type systems[1], some of them are more advanced than what Haskell provides (like true intersection unit types), some effect types (locks etc.) and more. So Java puts the burden on some very advanced -- but optional -- type systems. [1]: http://types.cs.washington.edu/checker-framework/current/che...

Yes, but not in any sense that matters to 99.9% of Java programmers in the field.

That's still more than Haskell and Rust developers in the field... ;) In any case, as Checker matures and becomes more accessible, it will be marketed more and I expect higher adoption.

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

#45

Post by krisdol »

microtonal wrote: post #25
Kwastie wrote: post #18

The author is missing the point. The fact that Optional can result in a nullpointer doesn't mean you should use in the same manner as null-checks. You shouldn't replace: if(x == null) { y = x.doSomething(); } with if(optionalX.isPresent()) { y = x.doSomething(); } You should replace it with: y = Optional.ofNullable(x) .map(ClassX::doSomething) .orElse(null);

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 does this when:

* the developer believes the Option/Result can never be None/Err (oh come on, just wait until you refactor your code a bit one day and miss a spot)

* the code is example code (I've had little luck finding "good" examples sprinkled about github)

* the developer is lazy (see above)

Allowing unsafe unwraps defeats a core purpose of rust, and the unwrap method shouldn't even exist in the API.

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

#47

Post by krisdol »

jkscm wrote: post #14

Using get() is just bad style and so is returning null where you could return Collections.emptyList(). Previous discussion on reddit: https://www.reddit.com/r/programming/comments/3pl7o0/java_8s... tl;dr: use map, orElseGet, orElse

>Using get() is just bad style and so is returning null where you could return Collections.emptyList().

I agree that you should never return null, but if get() is bad style I think you should send out that memo because I haven't yet seen codebases that agreed.

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

#48

Post by Ygor »

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"

Interesting, first time I heard SAP has a JVM implementation.

https://scn.sap.com/people/desiree.matas/blog/2011/12/07/sap...

Here is a presentation with some interesting points, wonder if anyone has any real-life experiences?

https://www.youtube.com/watch?v=arryAs9lqfE

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

#49

Post by microtonal »

krisdol wrote: post #45
microtonal wrote: post #25

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

Allowing unsafe unwraps defeats a core purpose of rust,

Definitely, but you can also still do this in Haskell (fromJust). But it's better than nullable types since you explicitly have call an unsafe method. (Assuming that you have set non-exhaustive pattern matching to be a warning/error.)

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

#50

Post by spiralpolitik »

We've been using Optional a lot in recent years (via Guava). It's useful, and has certainly reduced the number of NPE we've had slip through as it forces the developer to consider nullability up front. Looking forward to migrating to the Java 8 version when we upgrade to that JDK.

One addition that would be useful would be some syntactical sugar to reduce the verbosity of using Optional. But otherwise I'm happy and if you combine with @Nonnull and @Nullable annotations you get the best of both worlds.

Post reply on HN