News for hackers. Stuff that matters.
Re:JVM/Java: Null-Restricted and Nullable Types by layer8 on Friday August 02, 2024 @07:53AM (#41138076)
I agree that it is strange. What I would have expected is that (a) T? means nullable (the existing semantics) and T! means non-nullable, and that the default for plain T can be specified using a pragma-like declaration per source file (and/or per package file), and (b) the following LTS Java release would switch the global default. This would allow easy switching of projects (you can insert/update the pragma in an automated fashion), and also allow keeping the old default when needed.

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.

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.

Re:JVM/Java: Null-Restricted and Nullable Types by emccue on Saturday August 03, 2024 @03:30PM (#41148672)
To use the terminology from JSpecify:

    null-marked module accounting {
    
    }

Could very well be the sort of thing that comes next.