3 ms·

There's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that. I don't think this is something tha

There's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that. I don't think this is something that will only apply to null safety objects. Maybe initially, but I don't see there being major restrictions to extending this to other classes.

Tainnor 3y ago
> Java can't simply break that. And that, in turn, answers the question of where Kotlin is different enough from Java that it might be worth switching. Java is very strict on backwards compatibility. That has its advantages. But it also has a lot of downsides. Kotlin doesn't want/need to be backwards compatible, and it can afford to break semantics enough to make null not allowable(*) in non-nullable types. It's a trade-off, of course. But it explains why some people prefer Kotlin. (*) Save for Java interop.