Why can `call.receive<User>()` give me a User with fields as null?

# ktor

[Kenneth]

Why can call.receive<User>() give me a User with fields as null?

[Mike]

User just means you'll always have a User object. It doesn't guarantee anything about the contained class.

If the contained class has nullable properties, then they can be null.

If they're not nullable, then the JSON mapping or something should exception at some point...

[Kenneth]

data class User(val email: String, val password: String)

[Kenneth]

Shouldn't that guarantee that email and password are not null?

[Mike]

Only if the JSON mapper is in Kotlin. If you're using a Java mapper, it knows nothing about Kotlin's nullability, and won't enforce it.

This is one of those edge cases where Kotlin's null verification 'fails'.

[Kenneth]

Wow, I didn't know that.

[Kenneth]

I am using gson (https://ktor.io/servers/features/content-negotiation/gson.html)

[Mike]

I know about gson, but haven't used it.

Yes, the kotlin code gets turned into jvm byte code and the jvm does not have null/non-null types. That's compiler time checking that occurs for kotlin.

Once you're in bytecode/Java processing, you have to be careful.

Hopefully gson can be combined with some form of validation so it exceptions during conversion, but that will only get caught at runtime. So hopefully you're testing this so it doesn't get caught in production.

[Kenneth]

Yes, that's how I discovered it and why I am here.

[Kenneth]

So I have to check for null where null shouldn't be, and idea is complaining about it.

[Kenneth]

Works as expected with jackson