5 ms·

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 syste

by jcrites 11y ago

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 get() and risk an exception. So don't do that. I'm still glad get() is present because there are times when the human knows the value will always be present, but sometimes in a way that can't be encoded in the type system. Alternatively, sometimes an absent value is an error and get() is an acceptable way to check-and-throw. I agree with the suggestion that static analysis can be useful, though many users had that already with FindBugs or Fortify. If we're talking about annotations based analysis, then it only goes so far. Optional and streams provide useful new tools for documenting intentions from my perspective. Another reason I enjoy the type is because it makes it a little more reasonable to say that, at least in new code, all references are nonnull references by default, since they'd be Optional otherwise.

jontro 11y ago
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.
- pandler 11y ago
  > 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.
  - Zardoz84 11y ago
    I remember that somebody try to defend Java because have references instead of pointers so not is necessary to be worried about null pointers .. Ja!
  - acaloiar 11y ago
    I believe the point @jontro is making is that unsafe programming behavior is unsafe without regard to the language's constraints. Option simply makes it more difficult to behave unsafely. Of course a developer can still call .get() when the presence of a value is unknown, but the Option type lets them know they are being careless in doing so.
  - the_af 11y ago
    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.
- MereInterest 11y ago
  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.
  - Sharlin 11y ago
    Or, indeed, C++'s references which are non-nullable.
  - hibikir 11y ago
    In other languages that use Option types more natively, like Scala, anything that isn't optional is assumed to just not be null: The compiler doesn't guarantee it (it's not as if it can, we are dealing with a JVM here) but it works in practice. I've not seen a NullPointerException in years. Option has other advantages, like its compositional qualities (thanks to Option being a monad). So imagine the following code def foo(x:Option[String]) = x.filter(_.length<10).map(_ + "More data") If the function returns None if it receives either None or a string longer than 10 characters, and if we got Some("short "), foo will return Some("short More data"). The alternatives without an option type, involve at least a couple of branching statements, even if you have a non nullable type, to convert from nullable to not nullable, while Option does it all for us.
    - the_af 11y ago
      > I've not seen a NullPointerException in years [in Scala] This sounds odd. Does your code never interface with Java libraries and frameworks? I envy you! It's all too easy to forget to wrap a suspect value from Java-land with an Option(..). And cumbersome even if you do remember. And then, there's the code written by Scala novices who just love using nulls. Yes, yes, "code reviews", we all know they are always practiced all the time :/
      - mark242 11y ago
        The Scala landscape is very, very quickly creating their own libraries for similar popular Java libraries/frameworks. It is entirely possible to create an application, web or otherwise, that uses no Java libraries at all (save for the sbt dependency tree). As for "Scala novices who just love using nulls", if you're seeing that, then the coder in question missed day 1 of Scala training, which is always "if you are writing the word null, you are doing something wrong" (right up there with "if you are writing the word var, you are probably doing something wrong").
- Retra 11y ago
  Every reference in Java can be null. You should be thinking about it all the time. It's the Java language that forces you to think about nulls, not Optional.
bkv 11y ago
>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 general purpose option type. In fact, its intended use-case is very specific, according to a rather obscure SO answer by Brian Goetz: http://stackoverflow.com/a/26328555/547365 http://stackoverflow.com/a/26328555/547365 This is, of course, just tribal knowledge, meaning people are going to be doing shit with optional that they shouldn't, and it's going to be messy.
- peeters 11y ago
  >>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.
  - bkv 11y ago
    >Except these aren't at all the same. With a reference, you have no good way of telling whether your reference IS nullable. As the article mentions, we have annotations to do just that. >Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks. Again, if we're using static analysis to verify the correct use of Optional, why are we using optional at all? Why wouldn't we use static checks to verify null references can't be dereferenced, instead of hypothetical yet-to-be-implemented static checks that may not be implemented anyway? See https://github.com/findbugsproject/findbugs/issues/56 https://github.com/findbugsproject/findbugs/issues/56
rickette 11y ago
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/ http://sourceforge.net/p/findbugs/feature-requests/302/
- bkv 11y ago
  That is the old bug tracker. An issue was submitted on the official tracker and immediately closed. See https://github.com/findbugsproject/findbugs/issues/56 https://github.com/findbugsproject/findbugs/issues/56 for explanation.
  - deleted 11y ago
    [deleted]

by jcrites 11y ago

jontro 11y ago

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.

pandler 11y ago
> 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.
- Zardoz84 11y ago
  I remember that somebody try to defend Java because have references instead of pointers so not is necessary to be worried about null pointers .. Ja!
- acaloiar 11y ago
  I believe the point @jontro is making is that unsafe programming behavior is unsafe without regard to the language's constraints. Option simply makes it more difficult to behave unsafely. Of course a developer can still call .get() when the presence of a value is unknown, but the Option type lets them know they are being careless in doing so.
- the_af 11y ago
  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.
MereInterest 11y ago
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.
- Sharlin 11y ago
  Or, indeed, C++'s references which are non-nullable.
- hibikir 11y ago
  In other languages that use Option types more natively, like Scala, anything that isn't optional is assumed to just not be null: The compiler doesn't guarantee it (it's not as if it can, we are dealing with a JVM here) but it works in practice. I've not seen a NullPointerException in years. Option has other advantages, like its compositional qualities (thanks to Option being a monad). So imagine the following code def foo(x:Option[String]) = x.filter(_.length<10).map(_ + "More data") If the function returns None if it receives either None or a string longer than 10 characters, and if we got Some("short "), foo will return Some("short More data"). The alternatives without an option type, involve at least a couple of branching statements, even if you have a non nullable type, to convert from nullable to not nullable, while Option does it all for us.
  - the_af 11y ago
    > I've not seen a NullPointerException in years [in Scala] This sounds odd. Does your code never interface with Java libraries and frameworks? I envy you! It's all too easy to forget to wrap a suspect value from Java-land with an Option(..). And cumbersome even if you do remember. And then, there's the code written by Scala novices who just love using nulls. Yes, yes, "code reviews", we all know they are always practiced all the time :/
    - mark242 11y ago
      The Scala landscape is very, very quickly creating their own libraries for similar popular Java libraries/frameworks. It is entirely possible to create an application, web or otherwise, that uses no Java libraries at all (save for the sbt dependency tree). As for "Scala novices who just love using nulls", if you're seeing that, then the coder in question missed day 1 of Scala training, which is always "if you are writing the word null, you are doing something wrong" (right up there with "if you are writing the word var, you are probably doing something wrong").
Retra 11y ago
Every reference in Java can be null. You should be thinking about it all the time. It's the Java language that forces you to think about nulls, not Optional.

bkv 11y ago

>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 general purpose option type. In fact, its intended use-case is very specific, according to a rather obscure SO answer by Brian Goetz: http://stackoverflow.com/a/26328555/547365 http://stackoverflow.com/a/26328555/547365 This is, of course, just tribal knowledge, meaning people are going to be doing shit with optional that they shouldn't, and it's going to be messy.

peeters 11y ago
>>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.
- bkv 11y ago
  >Except these aren't at all the same. With a reference, you have no good way of telling whether your reference IS nullable. As the article mentions, we have annotations to do just that. >Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks. Again, if we're using static analysis to verify the correct use of Optional, why are we using optional at all? Why wouldn't we use static checks to verify null references can't be dereferenced, instead of hypothetical yet-to-be-implemented static checks that may not be implemented anyway? See https://github.com/findbugsproject/findbugs/issues/56 https://github.com/findbugsproject/findbugs/issues/56

rickette 11y ago

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/ http://sourceforge.net/p/findbugs/feature-requests/302/

bkv 11y ago
That is the old bug tracker. An issue was submitted on the official tracker and immediately closed. See https://github.com/findbugsproject/findbugs/issues/56 https://github.com/findbugsproject/findbugs/issues/56 for explanation.
- deleted 11y ago
  [deleted]