Re:OpenJDK mailing list: Null-safety and value types
by aardvark179 on Tuesday February 07, 2023 @08:12PM
(#34702693)
Reference types probably can’t be made non-billable by default as that would break too much. But
String! myString = “Definitely not null”;
doesn’t look too bad.Edit: it’s worth saying that a lot of careful thought around compatibility goes into features like this. That means the core libraries should be able to transition to non-billable types where this is already a run time requirement, and existing compiled jars must continue to work.
Re:OpenJDK mailing list: Null-safety and value types
by vips7L on Tuesday February 07, 2023 @09:10PM
(#34703193)
I don’t think anyone would really use String! everywhere.
Re:OpenJDK mailing list: Null-safety and value types
by aardvark179 on Wednesday February 08, 2023 @03:26AM
(#34705567)
I think you’ll see it creep into parameter types in the core JDK and it will work its way out from there.
Re:OpenJDK mailing list: Null-safety and value types
by kaba0 on Wednesday February 08, 2023 @12:45AM
(#34704588)
I think it can work in a binary-additive way — the class file gets a new attribute for nullness information, while missing it (older class files) default to “unspecified”. That can be safely consumed by new code, which will get the updated syntax with a new option (specified on a module/package/class basis) where ‘T’ means ‘T!’ and that should be a proper subset of previously compiling code, so I don’t think anything would break that way. Similarly to how generics and unchecked warnings were rolled out.
Re:OpenJDK mailing list: Null-safety and value types
by pjmlp on Wednesday February 08, 2023 @01:55PM
(#34712906)
See the !! debacle for C#11 to see how changing the default went.
So now we are back at warnings if non nullable references are enabled on the compiler settings, and eventually we can turn them into warnings as errors.
The biggest issue is the large ecosystem of existing libraries.
So `Point p = null` won’t type check, you would have to mark it as `Point?` where Point is a value (primitive) class. There were also points that it should work with the usual type inference, e.g. `final var p = methodThatReturnsNullablePoint()` would be inferred to `Point?`.