JVM/Java: Null-Restricted and Nullable Types

Re:JVM/Java: Null-Restricted and Nullable Types by unscaled on Friday August 02, 2024 @08:26AM (#41138273)

Kotlin does have types with unspecified nullability, although you cannot define it directly. Kotlin calls them "platform types"[1], and they're annotated with an exclamation mark (e.g. "String!" for a possibly-nullable string) in errors and diagnostics.

Both the term "platform types" and the exclamation mark symbol are confusing, but other than that Kotlin's approach works quite well. Since Kotlin has nullability from the very beginning, the programmer can't specify platform types directly, but Kotlin still needs to support them to maintain compatibility with underlying platforms that support unspecified nullability, such as the JVM and JavaScript.

With this approach, the defaults are still sane[2] (always non-nullable by default — everybody who thinks otherwise has learned nothing from Tony Hoare[2]), but the backward compatibility is maintained. But Kotlin got it easy, Java and C# also need to maintain compatibility with existing source code.

Neither Java's approach or C#'s approach seems ideal. The C# approach drastically changes the behavior of the code based on a compiler flag, while the Java approach makes the default into the worst possible choice.

I still lean towards the C# solution, because I think making "maybe-nullable" the easiest choice, means most programmers will choose it by default. Especially in an enterprise-friendly language like Java. Linters and compiler warnings would help in the long-term, but I think it will be many years before most of the Java code will be properly annotated for nullability. C# users will see more pain in the short term, but they will probably get to the promised land of clear nullability much faster.

[1] https://kotlinlang.org/docs/java-interop.html#null-safety-an...

[2] https://www.infoq.com/presentations/Null-References-The-Bill...

[ Parent | on HN ]

Re:JVM/Java: Null-Restricted and Nullable Types by simon_void on Friday August 02, 2024 @11:51AM (#41139878)

you failed to mention that Kotlin has platform types only if it's interoperates with Java. Platform types are for objects that come over from Java code (and therefore have unspecified nullability (assuming the Java code doesn't use nullability annotations)). Admittedly you provided a link that explains this, but how many people will follow the link? And yes, this detail feels kind of important. And yes, future Java (and Kotlin) will only have their version of platform types to interop with old Java code.

As a long-time Kotlin user I can only say: Nullability is nice! Once you know it, you won't want to code without it.

[ Parent | on HN ]

Re:JVM/Java: Null-Restricted and Nullable Types by unscaled on Friday August 02, 2024 @12:13PM (#41140066)

I did mention all of this:

"[...] but Kotlin still needs to support [platform types] to maintain compatibility with underlying platforms that support unspecified nullability, such as the JVM and JavaScript."

To be more accurate, "platform types" are not used with JavaScript, but you do get something similar in that case. I haven't worked with Kotlin/JS at all, but from my understanding if you do not have proper type definitions, you have to deal with dynamic types - which are also nullable.

[ Parent | on HN ]

Re:JVM/Java: Null-Restricted and Nullable Types by mmis1000 on Friday August 02, 2024 @12:06PM (#41139994)

The type kotlin generated from java code also inserts nullable specifier if java code have @NonNull or @Nullable specified.

When kotlin see these exist. It will convert the type to null enforced type instead. Which give you a tool to gradually convert you project to null enforced type if you can't convert it to kotlin at once.

[ Parent | on HN ]