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

31–40 of 197 posts

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

#31

Post by pron »

Brian Goetz's response: "They didn't solve the problem I thought they should have solved, so their solution is worthless." Thank you, internetz.[0]

In any case, that's not what Java's optional is there for[1]. Solving the safety problem is the job of Java 8's pluggable type systems[2] that are both more powerful than the static-analysis tools listed in the article and had Oracle's official support (in the form of JSR-308).

[0]: https://twitter.com/BrianGoetz/status/656860771196887040

[1]: http://stackoverflow.com/a/26328555/750563

[2]: http://types.cs.washington.edu/checker-framework/current/che...

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

#32

Post by Latty »

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.

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

#33

Post by mhaymo »

nrinaudo wrote: post #26
Cthulhu_ wrote: post #4

Earlier quoted context omitted.

The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException. The only value O…

I disagree with some of your points. The fact that you can get a null instance of Optional is not Java specific - Scala has the same issue, for example. Saying that Optional does not sort any problem because there is no way to enforce it cannot be null is just wrong - it sorts plenty of problems, just not all of them (you didn't mention the case of an optional that contains null, which is unpleasant as well). You can…

> you didn't mention the case of an optional that contains null

That's not possible in Java. `Optional.ofNullable(null)` returns `Optional.empty()`, and `Optional.of(null)` throws a NullPointerException.

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

#34

Post by pron »

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…

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

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

#35

Post by coldtea »

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…

>Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.)

And that's OK too, if less than ideal. The Optional type serves as a reminder to use it differently.

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

#36

Post by coldtea »

pron wrote: post #34
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…

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.

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

#37

Post by organsnyder »

malka wrote: post #21
w23j wrote: post #6

Earlier quoted context omitted.

At least one of the values of Optional is to communicate in the API that a value can be missing. The article mentions that: A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario." Making this clear to users of an API is something that nullable properties can not do. The user has to deliberately ig…

> A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario." Well, that's basically the same thing with any nullable return then. Wether I return T or Optional , there might be no record. Even worse, when I return T, you only have 2 cases : I return something, or I return null. With optional, you hav…

You should never have to check that the Optional itself is null. While that is allowed by the language, it is such an obvious error that static analysis tools could easily detect it.

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

#38

Post by w23j »

malka wrote: post #21
w23j wrote: post #6

Earlier quoted context omitted.

At least one of the values of Optional is to communicate in the API that a value can be missing. The article mentions that: A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario." Making this clear to users of an API is something that nullable properties can not do. The user has to deliberately ig…

> A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario." Well, that's basically the same thing with any nullable return then. Wether I return T or Optional , there might be no record. Even worse, when I return T, you only have 2 cases : I return something, or I return null. With optional, you hav…

I am not sure I understand.

I guess you are either saying (A) to treat every return type as possibly null or (B) to use your judgment when doing null checks of return types.

In case of (A): Do you want to write null-checks for methods like String.toUpperCase() or for user.getLastName()? That would lead to a lot of bloated, dead code. Also do you want to write error handling for all these cases you know can never happen?

In case of (B): NullPointerExceptions are most likely when the user of an API did not expect he might get a null value. For instance user.getDepartment -> null. "What? An employee does not have to have a department?!" In this case you force users of an API to guess if they might reive a null return value. And they might guess wrong, which either leads to dead code or NPEs. Using Optional as a return type makes the difference explicit.

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

#39

Post by bakhy »

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.

that makes sense. i think an important question here is - what does "return null" in a method which returns Optional do? will it return a null Optional, or will it return a non-null Optional which is empty?

sorry to rub it in, but Java needs value types. this whole issue, however maybe irrelevant, does not exist in C#.

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

#40

Post by desdiv »

_Codemonkeyism wrote: post #15

Shameless self plug "Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin" http://codemonkeyism.com/comparing-optionals-and-null-in-swi...

FYI your Scala example doesn't work.

    Welcome to Scala version 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).

    scala> var h:Option[String] = "Hello".some
    :7: error: value some is not a member of String
       var h:Option[String] = "Hello".some
Post reply on HN