2

Considering Kotlin Java Interop: Null Safety and Platform Types

Why is code like this legal in Kotlin?

fun envString(key: EnvVars): String {
    return System.getenv(key.toString())
}

getenv() can return null, as indicated by its JavaDoc:

Returns: the string value of the variable, or null if the variable is not defined in the system environment

So, learning Kotlin partly because it enforces strict(er) null-checks I am baffled by this design decision. It seems very counter the premise of "no more NPE" that supposedly underlies Kotlin.

Is there any document providing the reasoning behind this design?

Side note; As a user of Kotlin, would it be good practice to simply treat all non-primitive types coming from Java interop as nullable explicitly in my Kotlin code?

Improve this question
1

1 Answer 1

Reset to default
3

Is there any document providing the reasoning behind this design?

It is explained in the documentation under Calling Java code from Kotlin – Null Safety and Platform Types [bold emphasis mine]:

Any reference in Java may be null, which makes Kotlin's requirements of strict null-safety impractical for objects coming from Java.

Improve this answer
5
  • Huh I must have skipped that part. Technically a reason however it feels unsatisfying. I'd expect it to be more practical instead of less...
    – F.P
    Commented Jul 8, 2020 at 4:10
  • Java doesn't track null-safety, therefore, there is no way of knowing whether a method returns null or not. So, you have four possibilities: a) you treat all Java methods as returning nullable, which is annoying to deal with b) you treat all Java methods as returning non-nullable, which is lying to the type system, c) you create a catalog of all Java methods and annotate them with their nullability, which is simply impractical (you would have to annotate every Java method ever written in the history of mankind, and every method that ever will be written), or d) you introduce a special type …
    – Jörg W Mittag
    Commented Jul 8, 2020 at 4:20
  • … that says "this type belongs to a type system that works differently than ours". Now, extend this problem to the fact that Java is not the only platform Kotlin supports and you need to find a solution that works for every platform, not just the ones Kotlin currently supports (Java, ECMAScript, C) but also ones that it may want to support in the future (e.g. CLI).
    – Jörg W Mittag
    Commented Jul 8, 2020 at 4:22
  • 1
    It does make sense, however I would challenge the assumption behind option "a"; I'm not sure how it would be annoying to deal with. It ensures strict null checks, which is a good thing. If anything, you might add a symbol to indicate that the return value it guaranteed to be non-null as an option for the user, which would also put him in the position to handle runtime exceptions
    – F.P
    Commented Jul 8, 2020 at 4:29
  • The same question was part of a conference talk. It goes into some neat details such as the language principles :)
    – Diggi55
    Commented Dec 30, 2021 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.