![]() ![]() And for the sealed classes it may produce a second instance of Kotlin’s singleton object and make all following when expressions with this object incorrect. Since deserialization may create an instance without calling a user-defined constructor where all values are checked for null and set to defaults the resulting object can have nulls in non-nullable fields. Kotlin is not safe on deserialization: serialization is not safe and quite tricky even in Java but Kotlin adds a couple more potential issues to that: default values, sealed classes and nullability itself. ![]() That leads to two problems: 1) all ignored warnings or missed annotation can “leak” nulls into Kotlins “null-safe” variables 2) the Java code that was avoiding NPEs can start crashing after 1:1 conversion into Kotlin. Kotlin is not that safe on the boundaries: Nullable/NonNull annotations in Java code by default produce warnings in Java and compiler errors Kotlin and passing null to the NonNull parameter does nothing in Java, until you dereference this null, but it throws a runtime error immediately in Kotlin.How do we convert old Java code into Kotlin safely then? 1. So what’s the problem with NullPointerException in Kotlin? Both Google and JetBrains promote Kotlin as safe & interoperable language, not necessarily emphasizing enough that it’s not intrinsically free from NPEs, in fact, if misused Kotlin code will throw as many KNPEs and similar exceptions.
0 Comments
Leave a Reply. |