3 ms·

I don't quite get the problem as stated in the article. I assume it's a contrived example and the real (kotlin) code rather looks like: val foo: T? = null

I don't quite get the problem as stated in the article. I assume it's a contrived example and the real (kotlin) code rather looks like: val foo: T? = null Observable.just(foo).subscribe() Here foo is defined as nullable, hence the problem. If you make it val foo: T = null Observable.just(foo).subscribe() the kotlin compiler will bark on foo being null and you'll never have a runtime error. I think the motivating example should be described better but maybe I misunderstand it.

kodablah 9y ago
I think the point is different. Author is saying Java interop is fraught with runtime nullable issues that can't be caught at compile time for Java libs sans annotations. It has nothing to do with how it's set in Kotlin. Author says with nullable annotations on tge Java side, it'd bark at your first example too which is the real point.
- stewbrew 9y ago
  The author introduces his example with "Let’s take a look at a very short Kotlin + RxJava sample." But IMHO his sample describes a Java-only problem (and solution). He could have written a quite similar article without any mentioning of kotlin.
  - kodablah 9y ago
    > He could have written a quite similar article without any mentioning of kotlin Almost. The point about the language itself respecting the Java nullability annotations is apt.
masklinn 9y ago
> I don't quite get the problem as stated in the article. > Here foo is defined as nullable, hence the problem. How do you know it's "the problem"? The answer is that you don't until it blows up in your face, because this is a Java interop call. And of course the local could come from an other call into Java which returns a nullable reference, or it could make complete sense for it to be nullable.
- smichel17 9y ago
  Remove part of your sentence, and I think you've answered your own question. > How do you know it's "the problem"? [...] because this is a Java interop call. If you're making platform calls, you know you have to deal with nulls (or at least, you should, in my opinion). So you declare returns nullable and avoid passing nulls unless that's documented to be okay. Kotlin's Elvis operator makes this really easy: val a: String? = null val b: String = a ?: "alternative"
taeric 9y ago
Assume that there is a valid reason for the "foo" to be allowed as null, but that you wanted to guard against allowing calls to Observable.just to take in a null. For example, "foo" is a variable at your boundary between the user and the main logic of the system, and the Observable is in the heart of your code and you expect that it should never be passed nulls. Now, to your point, you could just make sure that you filter the "nullable" foo through a non-nullable "bar." Which is ultimately what you will do. The article's point is that if the Observable part had been written in Kotlin, this would have likely been the default. Adding a marker to say "nullable" is how you have to do it in Kotlin. In Java, it is the opposite. You have to add a marker saying non-nullable. At least, that is my reading.
pdpi 9y ago
The problem isn't with `foo`, it's with how Kotlin's Java interop treats `just`. Because Java doesn't have a language-level concept of non-nullability, Kotlin's interpretation of the type signature for `just` must accept nulls (sure enough, non-nullability is enforced at run time inside RxJava). Kotlin trains you to expect nullability to be a compile-time constraint, and has borderline frictionless with Java. Put the two together, and it's very easy to walk into a runtime-error trap.
- stewbrew 9y ago
  I understand that. I still think the example isn't well chosen. Whatever.

kodablah 9y ago

I think the point is different. Author is saying Java interop is fraught with runtime nullable issues that can't be caught at compile time for Java libs sans annotations. It has nothing to do with how it's set in Kotlin. Author says with nullable annotations on tge Java side, it'd bark at your first example too which is the real point.

stewbrew 9y ago
The author introduces his example with "Let’s take a look at a very short Kotlin + RxJava sample." But IMHO his sample describes a Java-only problem (and solution). He could have written a quite similar article without any mentioning of kotlin.
- kodablah 9y ago
  > He could have written a quite similar article without any mentioning of kotlin Almost. The point about the language itself respecting the Java nullability annotations is apt.

masklinn 9y ago

> I don't quite get the problem as stated in the article. > Here foo is defined as nullable, hence the problem. How do you know it's "the problem"? The answer is that you don't until it blows up in your face, because this is a Java interop call. And of course the local could come from an other call into Java which returns a nullable reference, or it could make complete sense for it to be nullable.

smichel17 9y ago
Remove part of your sentence, and I think you've answered your own question. > How do you know it's "the problem"? [...] because this is a Java interop call. If you're making platform calls, you know you have to deal with nulls (or at least, you should, in my opinion). So you declare returns nullable and avoid passing nulls unless that's documented to be okay. Kotlin's Elvis operator makes this really easy: val a: String? = null val b: String = a ?: "alternative"

taeric 9y ago

Assume that there is a valid reason for the "foo" to be allowed as null, but that you wanted to guard against allowing calls to Observable.just to take in a null. For example, "foo" is a variable at your boundary between the user and the main logic of the system, and the Observable is in the heart of your code and you expect that it should never be passed nulls. Now, to your point, you could just make sure that you filter the "nullable" foo through a non-nullable "bar." Which is ultimately what you will do. The article's point is that if the Observable part had been written in Kotlin, this would have likely been the default. Adding a marker to say "nullable" is how you have to do it in Kotlin. In Java, it is the opposite. You have to add a marker saying non-nullable. At least, that is my reading.

pdpi 9y ago

The problem isn't with `foo`, it's with how Kotlin's Java interop treats `just`. Because Java doesn't have a language-level concept of non-nullability, Kotlin's interpretation of the type signature for `just` must accept nulls (sure enough, non-nullability is enforced at run time inside RxJava). Kotlin trains you to expect nullability to be a compile-time constraint, and has borderline frictionless with Java. Put the two together, and it's very easy to walk into a runtime-error trap.

stewbrew 9y ago
I understand that. I still think the example isn't well chosen. Whatever.