Fix #7759: Rename JavaNull -> UncheckedNull

[odersky]

Before releasing the Dotty version with explicit nulls later this week, we want to make sure we get the names right, since these are hard to fix once people have started using them.

@abeln @olhotak @noti0na1 are you OK with UncheckedNull?

[odersky]

One other reason to go with UncheckedNull instead of JavaNull is that we might also need it for Scala 2.x code. @abeln @olhotak @noti0na1 Did you already consider the case of mixed Scala 2/Scala 3 codebases? How should this be handled?

[olhotak]

Our position on Scala 2 code is to unsoundly assume that the types do not include null (i.e. to not nullify the types like we do for Java types). The underlying assumption is that Scala 2 code will eventually be ported to Scala 3, so we will eventually be sound once that happens, but we remain temporarily unsound to ease migration.

If instead we tried to be sound immediately, that would increase the migration burden, and more importantly, it might require a second migration back once the Scala 2 code does get ported to Scala 3. For example, if a Scala 2 method currently returns ArrayBuffer[AnyRef], in the first migration, you would have to modify the calling code to expect ArrayBuffer[AnyRef | Null], but when later the Scala 2 code is ported to Scala 3, you would have to migrate the calling code back to ArrayBuffer[AnyRef]. We especially want to avoid this double migration.

BTW I like the term UncheckedNull.

[odersky]

Our position on Scala 2 code is to unsoundly assume that the types do not include null (i.e. to not nullify the types like we do for Java types). The underlying assumption is that Scala 2 code will eventually be ported to Scala 3, so we will eventually be sound once that happens, but we remain temporarily unsound to ease migration.

That makes sense. null is used rarely in Scala anyway, so adding it everywhere to Scala-2 compiled classes just because we are not sure is probably overkill.