6 ms·

“… it has the more ambitious agenda to heal the rift between primitives and objects.” I have been waiting for these fixes to the language since I was first int

“… it has the more ambitious agenda to heal the rift between primitives and objects.” I have been waiting for these fixes to the language since I was first introduced to Rust which got the type system “correct” where Java had left a lot to be desired. The big thing that Java will get beyond generics and such being cleaned up for all types, is true Optional types. That is, a stack based Optional that is itself not null, but tracks something that might be null in the interior. It will take a long time to update the ecosystem to correct this, but when it comes it will make Java a much “safer” language to develop in, that is a class of runtime errors can be avoided and caught at compile time. This will be great, and I look forward to the day when it comes.

kaba0 5y ago
Due to backwards compatibility Optionals will be value classes, not primitives so null will be a possible value for them as far as I know. But it will be possible to optimize it at many places (mostly as return types perhaps).
- bluejekyll 5y ago
  I’d be interested in a new type in that case. Option…
  - Twisol 5y ago
    If I understand the Valhalla proposed design [0], every primitive reference type `X` will have an associated primitive value type `X.val`, while every primitive value type `X` will have an associated primitive reference type `X.ref`. Which one gets to be called `X` is a function of how you declare it -- `primitive class X.val {}` gives primacy to the reference type. So, if `Optional` will continue to be a reference type, you should be able to use `Optional.val` to use the associated value type. [0] https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401
    - _old_dude_ 5y ago
      I believe JEP 401 has not yet been updated to the new model, there is no .val anymore, instead there are nullable value types and non nullable primitive types, only the latter has a .ref box because the former is a reference. Optional will be retrofitted to a value class not a primitive class, you get flattening but only on stack (parameter type or return type) not on heap (field). I don't really understand the end of the part3 (the VM model), so i may be wrong.
- fnord77 5y ago
  a null Optional will be pretty disappointing
  - ithkuil 5y ago
    if (opt != null && opt.isPresent() && opt.get() != "")
  - dtech 5y ago
    It's possible in current Java
  - samus 5y ago
    It already is :)
- syspec 5y ago
  Optionull
stepbeek 5y ago
Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/procedural language again after fleeing to scala for a few years.
- bluejekyll 5y ago
  Yes. Kotlin is good, but there is a lot of Java out there that needs to be supported. Have you experimented with converting entire projects of Java to Kotlin?
  - The_rationalist 5y ago
  - halpert 5y ago
    Why would you convert the entire project to Kotlin? It’s trivial to mix the two languages, and in fact most Kotlin applications depend on Java libraries.
    - pjmlp 5y ago
      Jet Brains seems to want ot create an ecosystem of their own, Kotlin still depends on Java is more accurate.
      - halpert 5y ago
        I don’t think that’s true. One of the biggest use cases for Kotlin is Android development. Interop between Kotlin, Java libraries, and the Android SDK is completely seamless.
        62951413 5y ago
        It's hard to be certain but we have seen this story in Scala. Among the advantages advertised early was interoperability with Java and access to its huge ecosystem. In practice the Scala ecosystem is completely different (well, Akka is a special case popular in Java projects too). As a trivial example people would rather use ScalaPB instead of officially supported Java library. When I worked on a Kotlin-based system people were adamant to use github.com/JetBrains/Exposed. Which had a couple pages of documentation and was missing features. And then again there's politics. Big/successful companies always end up re-inventing PL wheels. The whole GOOG/ORCL mess gave GOOG incentive to fragment the Java ecosystem too.
Matthias247 5y ago
The main thing of Rust that Java can’t provide even after Valhalla is compile time thread safety guarantees. I find those in the meantime one of the biggest advantages of using Rust - and miss it in all other programming languages. Questions like „can I refactor this code to make it parallel und use the database client / IO stream / etc from multiple threads simply answer themselves. Apartment from that I think the type system power of Java/Kotlin in the near future is good enough and a nice blend of complexity and getting things done. And with Valhalla, Loom and modern GCs a lot of performance concerns should also be removed
- kaba0 5y ago
  Rust can only guarantee that no data race will happen. Other race conditions are still possible, so I don’t really see Rust that much safer than Java. Concurrency is hard everywhere.
  - charleslmunger 5y ago
    Indeed. I recommend using tsan for java. https://wiki.openjdk.java.net/display/tsan/Main https://wiki.openjdk.java.net/display/tsan/Main But the types of races I struggle with in java I suspect are similarly hard in Rust. Here's two pieces of concurrent code I struggled with: https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/ExecutionSequencer.java#L286 https://github.com/google/guava/blob/master/guava/src/com/go... https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/SequentialExecutor.java#L162 https://github.com/google/guava/blob/master/guava/src/com/go... I'm not sure reasoning about the correctness of those would be easier in Rust, but if there are any rust experts reading this I'd love your perspective.
    - kaba0 5y ago
      Thanks, I haven’t seen tsan before. Java also has JML but I don’t know how much does it help regarding concurrency.
    - Matthias247 5y ago

kaba0 5y ago

Due to backwards compatibility Optionals will be value classes, not primitives so null will be a possible value for them as far as I know. But it will be possible to optimize it at many places (mostly as return types perhaps).

bluejekyll 5y ago
I’d be interested in a new type in that case. Option…
- Twisol 5y ago
  If I understand the Valhalla proposed design [0], every primitive reference type `X` will have an associated primitive value type `X.val`, while every primitive value type `X` will have an associated primitive reference type `X.ref`. Which one gets to be called `X` is a function of how you declare it -- `primitive class X.val {}` gives primacy to the reference type. So, if `Optional` will continue to be a reference type, you should be able to use `Optional.val` to use the associated value type. [0] https://openjdk.java.net/jeps/401 https://openjdk.java.net/jeps/401
  - _old_dude_ 5y ago
    I believe JEP 401 has not yet been updated to the new model, there is no .val anymore, instead there are nullable value types and non nullable primitive types, only the latter has a .ref box because the former is a reference. Optional will be retrofitted to a value class not a primitive class, you get flattening but only on stack (parameter type or return type) not on heap (field). I don't really understand the end of the part3 (the VM model), so i may be wrong.
fnord77 5y ago
a null Optional will be pretty disappointing
- ithkuil 5y ago
  if (opt != null && opt.isPresent() && opt.get() != "")
- dtech 5y ago
  It's possible in current Java
- samus 5y ago
  It already is :)
syspec 5y ago
Optionull

stepbeek 5y ago

Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/procedural language again after fleeing to scala for a few years.

bluejekyll 5y ago
Yes. Kotlin is good, but there is a lot of Java out there that needs to be supported. Have you experimented with converting entire projects of Java to Kotlin?
- The_rationalist 5y ago
- halpert 5y ago
  Why would you convert the entire project to Kotlin? It’s trivial to mix the two languages, and in fact most Kotlin applications depend on Java libraries.
  - pjmlp 5y ago
    Jet Brains seems to want ot create an ecosystem of their own, Kotlin still depends on Java is more accurate.
    - halpert 5y ago
      I don’t think that’s true. One of the biggest use cases for Kotlin is Android development. Interop between Kotlin, Java libraries, and the Android SDK is completely seamless.
      - 62951413 5y ago
        It's hard to be certain but we have seen this story in Scala. Among the advantages advertised early was interoperability with Java and access to its huge ecosystem. In practice the Scala ecosystem is completely different (well, Akka is a special case popular in Java projects too). As a trivial example people would rather use ScalaPB instead of officially supported Java library. When I worked on a Kotlin-based system people were adamant to use github.com/JetBrains/Exposed. Which had a couple pages of documentation and was missing features. And then again there's politics. Big/successful companies always end up re-inventing PL wheels. The whole GOOG/ORCL mess gave GOOG incentive to fragment the Java ecosystem too.

Matthias247 5y ago

The main thing of Rust that Java can’t provide even after Valhalla is compile time thread safety guarantees. I find those in the meantime one of the biggest advantages of using Rust - and miss it in all other programming languages. Questions like „can I refactor this code to make it parallel und use the database client / IO stream / etc from multiple threads simply answer themselves. Apartment from that I think the type system power of Java/Kotlin in the near future is good enough and a nice blend of complexity and getting things done. And with Valhalla, Loom and modern GCs a lot of performance concerns should also be removed

kaba0 5y ago
Rust can only guarantee that no data race will happen. Other race conditions are still possible, so I don’t really see Rust that much safer than Java. Concurrency is hard everywhere.
- charleslmunger 5y ago
  Indeed. I recommend using tsan for java. https://wiki.openjdk.java.net/display/tsan/Main https://wiki.openjdk.java.net/display/tsan/Main But the types of races I struggle with in java I suspect are similarly hard in Rust. Here's two pieces of concurrent code I struggled with: https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/ExecutionSequencer.java#L286 https://github.com/google/guava/blob/master/guava/src/com/go... https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/SequentialExecutor.java#L162 https://github.com/google/guava/blob/master/guava/src/com/go... I'm not sure reasoning about the correctness of those would be easier in Rust, but if there are any rust experts reading this I'd love your perspective.
  - kaba0 5y ago
    Thanks, I haven’t seen tsan before. Java also has JML but I don’t know how much does it help regarding concurrency.
  - Matthias247 5y ago