3 ms·

I don't think I agree. C# added it and its gone well and Java is adding null safety without breaking backwards compatibility at all.

by vips7L 2y ago

cubefox 2y ago
Types in old code may be nullable, or not, the compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere. That's not very practical. Moreover, the old code itself may still produce null pointer exceptions.
- vips7L 2y ago
  But that doesn't break compatibility like you claimed and it also doesn't support your conclusion that it will not likely be used. > he compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere This isn't necessarily true. Java's approach is to have 3 types: nullable, non-null, and platform (just like Kotlin). Platform types are types without nullness markers and don't require strict null checks to prevent backwards compatibility breaking. Yes, old code may still product null pointers, but we don't need 100% correctness right away. At some point platform types will be 1% of code in the wild rather than 100%.
  - cubefox 2y ago
    > At some point platform types will be 1% of code in the wild rather than 100%. In the case of Java this could take decades. Or people simply continue to write platform types because they are lazy (the compiler doesn't force them). Then platform types will never decrease substantially.
    - vips7L 2y ago
      I don't think that's true and I don't think there is any data to back that up. We've already seen in the C# community rapid adoption of nullness markers. This whole goal post moving and the idea that if we can't have 100% we shouldn't do it at all is a bit exhausting so I think I'm done here. Cheers man.
- valenterry 2y ago
  Well yeah, there is no way around this on the JVM. That's one of the JVM's problems/drawbacks. Everything can be null and everything can throw exceptions. But in practice, as long as you use only Scala libraries and are careful when using Java libraries it's not really an issue. (speaking as a professional Scala developer for many many years)
neonsunset 2y ago
If anything, it's a default to have them on in any reasonably recent project - you get that with all templates, default projects, etc. Actively maintained libraries are always expected to come with NRT support. If this is not the case, it's usually a sign the library is maintained by developers who ignore the conventions/guidelines and actively went out of their way to disable them, which usually a strong signal to either file an issue or completely avoid such library. Similar logic applies to code that has migrated over to .NET 6/8, or any newly written code past ~.NET 5.

I don't think I agree. C# added it and its gone well and Java is adding null safety without breaking backwards compatibility at all.

by vips7L 2y ago

I don't think I agree. C# added it and its gone well and Java is adding null safety without breaking backwards compatibility at all.

cubefox 2y ago

Types in old code may be nullable, or not, the compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere. That's not very practical. Moreover, the old code itself may still produce null pointer exceptions.

vips7L 2y ago
But that doesn't break compatibility like you claimed and it also doesn't support your conclusion that it will not likely be used. > he compiler doesn't know, so the only way the compiler can ensure null safety for using old code is by enforcing you to do null checks everywhere This isn't necessarily true. Java's approach is to have 3 types: nullable, non-null, and platform (just like Kotlin). Platform types are types without nullness markers and don't require strict null checks to prevent backwards compatibility breaking. Yes, old code may still product null pointers, but we don't need 100% correctness right away. At some point platform types will be 1% of code in the wild rather than 100%.
- cubefox 2y ago
  > At some point platform types will be 1% of code in the wild rather than 100%. In the case of Java this could take decades. Or people simply continue to write platform types because they are lazy (the compiler doesn't force them). Then platform types will never decrease substantially.
  - vips7L 2y ago
    I don't think that's true and I don't think there is any data to back that up. We've already seen in the C# community rapid adoption of nullness markers. This whole goal post moving and the idea that if we can't have 100% we shouldn't do it at all is a bit exhausting so I think I'm done here. Cheers man.
valenterry 2y ago
Well yeah, there is no way around this on the JVM. That's one of the JVM's problems/drawbacks. Everything can be null and everything can throw exceptions. But in practice, as long as you use only Scala libraries and are careful when using Java libraries it's not really an issue. (speaking as a professional Scala developer for many many years)

neonsunset 2y ago

If anything, it's a default to have them on in any reasonably recent project - you get that with all templates, default projects, etc. Actively maintained libraries are always expected to come with NRT support. If this is not the case, it's usually a sign the library is maintained by developers who ignore the conventions/guidelines and actively went out of their way to disable them, which usually a strong signal to either file an issue or completely avoid such library. Similar logic applies to code that has migrated over to .NET 6/8, or any newly written code past ~.NET 5.