In this particular case it goes further. C#'s nullable-reference types are useful, have a few problems, e.g.
• The feature is compile-time only (unsurprising considering the type narrowing approach is very similar to how TypeScript works)
• It interacts weirdly with Nullable<T> for structs since that already came before, uses some of the same syntax, but works differently because it's actually a type at runtime.
Java seems to have the nice position here to make it consistent across value types and reference types (assuming Project Valhalla is ever done) and they seem to have opted to retain the types at runtime as well which will cause runtime checks. This may cause gripes about performance, but from a correctness standpoint it's definitely much nicer than just having APIs that tell you that null won't ever occur, only to still have that problem in certain cases.
• The feature is compile-time only (unsurprising considering the type narrowing approach is very similar to how TypeScript works)
• It interacts weirdly with Nullable<T> for structs since that already came before, uses some of the same syntax, but works differently because it's actually a type at runtime.
Java seems to have the nice position here to make it consistent across value types and reference types (assuming Project Valhalla is ever done) and they seem to have opted to retain the types at runtime as well which will cause runtime checks. This may cause gripes about performance, but from a correctness standpoint it's definitely much nicer than just having APIs that tell you that null won't ever occur, only to still have that problem in certain cases.