4 ms·
"It is not a goal to require programs to explicitly account for all null values that might occur; unaccounted-for null values may cause compile-time warnings, b
by Sankozi 2y ago
"It is not a goal to require programs to explicitly account for all null values that might occur; unaccounted-for null values may cause compile-time warnings, but not compile-time errors"
This is a bad decision. Java is mostly statically typed language, why introduce another dynamic behaviour? Hope there will be easy way to promote such warnings to errors.
- yxhuvud 2y agoThey can't do that or it will break all java programs in existence. Enforcing that would force all programs to be rewritten to handle null responses everywhere. With this addition they can apply the forced null handling to only operations involving the new types, and thus not break anything. And yes, languages where the type systems force handling null/nil in all cases is a lot nicer. But that is not what the current Java is. This will still be a big improvement.
- Sankozi 2y agoIt will only break existing programs if they start introducing Type! into existing APIs. I understand that introducing ! types in existing Java libraries would be nice, but I much prefer the ! mechanism to be more "correct". I agree that it will be a big improvement either way. It seems we need some annotation akin to @Deprecated(forRemoval = true). Something like @NotNull(willBeEnforced = true) that would only emit a warning but informs the user that soon there will be a breaking change related to nullability.