Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null).

As mentioned in the relevant JEP[1]:

"A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol."

Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null."

Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value."

So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe).

[1] https://openjdk.org/jeps/8316779

I actually missed that it was restricted to value classes, thanks for the correction, this is unfortunate. To be fair null-checking (or just documenting null-safety) the data classes is the main use case, as other cases of nullability (class collaborators, eg a repository injected into a service) are usually a bug and quickly fixed.

The data that flows through the app at runtime is the big issue, and even just documenting null-safety at the API interfaces goes a long way in making refactorings safer and maintenance less of a pain. Those are usually records nowadays (DTOs, VOs, Entities).