4 ms·

Optional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a

Optional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a huge difference, and exposes so many "I didn't know that could be null" spaces.

vips7L 6y ago
I just see that as a non-argument. No one in their right mind returns null instead of Optional.empty() and I've never seen it done in the wild. Regardless in kotlin you can simply do: val s: String? = null return s as String or val s: String? = null !!s.trim() and lose all safety around nullability. Both hinge on a rogue developer not following best practices.
- The_Colonel 6y ago
  I've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev). What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.
pjmlp 6y ago
Valhalla will change that, all value like classes are going to be value types in post Valhalla.
- eonwe 6y ago
  Yes, that will happen eventually. Valhalla has now been coming since 2014, so I would not expect it to help any software project in the next two years or so.
  - pjmlp 6y ago
    Java isn't Python, so great thought is being given to keeping those 25 year old jars running on an Valhalla world. Experimental builds are available.
- scns 6y ago
  Yes, but all these features that are coming to Java in the future are worthless when you want/need to write software now.
  - pjmlp 6y ago
    Experimental builds are available. And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART. Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
- The_Colonel 6y ago
  But value types are not drop in replacement for reference types, i.e. you will still have null safety issues in a lot of cases.
  - pjmlp 6y ago
    Depends if one makes use of PMD or not. Surely using nullable annotations is more typing than ! or ?, but that is about it, no need to change languages.
    - The_Colonel 6y ago
      Which nullable annotations? There is no standard (JSR 305 is not a standard). > Surely using nullable annotations is more typing than ! or ? That's Java's answer to many things but it seriously hurts readability (among other things). I don't want to scroll over pages of getters and setters with annotations. Simple and common things should be expressible succinctly. > but that is about it, no need to change languages. Null safety is such basic need that it needs to be part of a modern high level language.
      - pjmlp 6y ago
        The standard is what PMD understands, that is good enough. Not everything needs getters and setters, it is just cargo cult generating them blindly. Also Java has records now, but you aren't going to get them on Android anytime soon. Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
        The_Colonel 6y ago
        PMD itself is no standard though. Best standards are enforced in compiler anyway. > Not everything needs getters and setters, it is just cargo cult generating them blindly. JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately. Setters/getters are just one example of Java's boilerplateness. > Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless. Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin? I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.

vips7L 6y ago

I just see that as a non-argument. No one in their right mind returns null instead of Optional.empty() and I've never seen it done in the wild. Regardless in kotlin you can simply do: val s: String? = null return s as String or val s: String? = null !!s.trim() and lose all safety around nullability. Both hinge on a rogue developer not following best practices.

The_Colonel 6y ago
I've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev). What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.

pjmlp 6y ago

Valhalla will change that, all value like classes are going to be value types in post Valhalla.

eonwe 6y ago
Yes, that will happen eventually. Valhalla has now been coming since 2014, so I would not expect it to help any software project in the next two years or so.
- pjmlp 6y ago
  Java isn't Python, so great thought is being given to keeping those 25 year old jars running on an Valhalla world. Experimental builds are available.
scns 6y ago
Yes, but all these features that are coming to Java in the future are worthless when you want/need to write software now.
- pjmlp 6y ago
  Experimental builds are available. And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART. Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
The_Colonel 6y ago
But value types are not drop in replacement for reference types, i.e. you will still have null safety issues in a lot of cases.
- pjmlp 6y ago
  Depends if one makes use of PMD or not. Surely using nullable annotations is more typing than ! or ?, but that is about it, no need to change languages.
  - The_Colonel 6y ago
    Which nullable annotations? There is no standard (JSR 305 is not a standard). > Surely using nullable annotations is more typing than ! or ? That's Java's answer to many things but it seriously hurts readability (among other things). I don't want to scroll over pages of getters and setters with annotations. Simple and common things should be expressible succinctly. > but that is about it, no need to change languages. Null safety is such basic need that it needs to be part of a modern high level language.
    - pjmlp 6y ago
      The standard is what PMD understands, that is good enough. Not everything needs getters and setters, it is just cargo cult generating them blindly. Also Java has records now, but you aren't going to get them on Android anytime soon. Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
      - The_Colonel 6y ago
        PMD itself is no standard though. Best standards are enforced in compiler anyway. > Not everything needs getters and setters, it is just cargo cult generating them blindly. JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately. Setters/getters are just one example of Java's boilerplateness. > Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless. Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin? I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.