3 ms·
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 int
by 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 agoDo you have a pointer?
- ptx 5y agohttps://kotlinlang.org/docs/null-safety.html https://kotlinlang.org/docs/null-safety.html
- vips7L 5y agoYeah I’m hoping Java takes the C# approach with a compile option that can enable that type of null safety.
- pjmlp 5y agoThe 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 agoJava 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