3 ms·

See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default

See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554

brabel 3y ago
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 https://openjdk.org/jeps/8316779
- MrBuddyCasino 3y ago
  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).

brabel 3y ago

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 https://openjdk.org/jeps/8316779

MrBuddyCasino 3y ago
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).