Re:JVM/Java: Null-Restricted and Nullable Types
by twic on Friday August 02, 2024 @12:09PM
(#41140022)
Sounds pretty good. But i think the mode selector has to be in the source code where a reader can see it, which rules out a compiler switch.
The current proposal doesn't exclude this possibility in the future, does it. Maybe one day you will be able to declare a class
public class! MyClass {
or have a package-info file which says package! com.initech.accounting;
Re:JVM/Java: Null-Restricted and Nullable Types
by layer8 on Friday August 02, 2024 @12:15PM
(#41140083)
The compiler switch would be for emulating (or for disabling) the global switchover that we want to take place at some point. We currently have the wrong default, so to speak, and we’d want to change that at some point. Then it is useful to already be able to do that in earlier releases, and also to be able to revert to the old default in later releases.
Otherwise, I agree that it should be in the source. In practice, looking for the presence or absence for T? vs. T! will be a good heuristic for whether the code assumes the new or the old semantics.
In addition, the existing @Nonnull annotation could have been leveraged as being the way how nonnullable type occurrences are indicated in class files, providing two-way compatibility for old JDKs.