3 ms·

I’m pretty sure returning Optionals from a method always makes them “escape” and become heap allocated. Hopefully if Valhalla ever lands Optional will be a prim

by vips7L 5y ago

I’m pretty sure returning Optionals from a method always makes them “escape” and become heap allocated. Hopefully if Valhalla ever lands Optional will be a primitive class. Here’s a fascinating read on the current state of HotSpot escape analysis: https://gist.github.com/JohnTortugo/c2607821202634a6509ec3c321ebf370 https://gist.github.com/JohnTortugo/c2607821202634a6509ec3c3...

mwcampbell 5y ago
And this is one reason why I think Kotlin's approach to nullability is better than Scala's Option or Java 8's Optional. Also, the Kotlin solution has better interop with legacy Java APIs.
- bonzini 5y ago
  Do you have a pointer?
  - ptx 5y ago
    https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html
- vips7L 5y ago
  Yeah I’m hoping Java takes the C# approach with a compile option that can enable that type of null safety.
  - pjmlp 5y ago
    The C# approach will take decades for .NET shops to wrap their minds around it. 2021 was the first year I deploy anything related to .NET Core in production, and it was still .NET Core 3.1. Will this velocity no one is going to their .NET repos and rewrite the libraries with the required annotations to keep the compiler happy. If you want null safety in Java today, just make use of @Nullable, a good IDE with static analysis, and deploy PMD, FindBugs or SonarQube into the CI/CD pipeline.
- vbezhenar 5y ago
  Java Optional is not a general replacement for nulls (although people might use it this way). It's a way to replace nulls in method return value, when those nulls indicate missing value. It's a subtle philosophical distinction, but I think that it's worth to remember it. If you want to improve nulls handling in Java, you should use @NotNull annotation and corresponding linters. https://stackoverflow.com/a/26328555/315129 https://stackoverflow.com/a/26328555/315129
comex 5y ago
That post says that escape analysis is "heavily dependent on methods pertaining to candidate objects being inlined", implying that the check for whether something is returned from a method happens after inlining. The post then complains that the inliner's decision of whether to inline isn't informed by whether doing so would be beneficial for escape analysis. But that shouldn't matter for this particular microbenchmark where, according to the post, the function returning the optional does get inlined.

by vips7L 5y ago

mwcampbell 5y ago

And this is one reason why I think Kotlin's approach to nullability is better than Scala's Option or Java 8's Optional. Also, the Kotlin solution has better interop with legacy Java APIs.

bonzini 5y ago
Do you have a pointer?
- ptx 5y ago
  https://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html
vips7L 5y ago
Yeah I’m hoping Java takes the C# approach with a compile option that can enable that type of null safety.
- pjmlp 5y ago
  The C# approach will take decades for .NET shops to wrap their minds around it. 2021 was the first year I deploy anything related to .NET Core in production, and it was still .NET Core 3.1. Will this velocity no one is going to their .NET repos and rewrite the libraries with the required annotations to keep the compiler happy. If you want null safety in Java today, just make use of @Nullable, a good IDE with static analysis, and deploy PMD, FindBugs or SonarQube into the CI/CD pipeline.
vbezhenar 5y ago
Java Optional is not a general replacement for nulls (although people might use it this way). It's a way to replace nulls in method return value, when those nulls indicate missing value. It's a subtle philosophical distinction, but I think that it's worth to remember it. If you want to improve nulls handling in Java, you should use @NotNull annotation and corresponding linters. https://stackoverflow.com/a/26328555/315129 https://stackoverflow.com/a/26328555/315129

comex 5y ago

That post says that escape analysis is "heavily dependent on methods pertaining to candidate objects being inlined", implying that the check for whether something is returned from a method happens after inlining. The post then complains that the inliner's decision of whether to inline isn't informed by whether doing so would be beneficial for escape analysis. But that shouldn't matter for this particular microbenchmark where, according to the post, the function returning the optional does get inlined.