Revisiting default values

[Kevin Bourrillion]

It sounds like this debate is between `null` and a value which really is
the *moral equivalent* of `null`. You basically would have two kinds of
nullability that look different from each other.

If you can surface both cases as literal `null` then nullness analysis
tools could work the same way for both. That seems really appealing to me.


On Mon, Jul 13, 2020 at 11:20 AM Dan Smith <daniel.smith at oracle.com> wrote:

> > On Jul 10, 2020, at 12:23 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> >
> > Option G: JVM support for default instance guards
> >
> > Inline class files can indicate that their default instance is invalid.
> All attempts to operate on that instance (via field/method accesses, other
> than 'withfield') result in an exception.
> >
> > This tightens up Option F, making it just as impossible to access
> members of the default instance as it is to access members of 'null'.
> >
> > Same issues as Option E regarding adding a "new NPE" to the platform.
>
> There's a variant of this that deserves spelling out:
>
> ---
>
> Option J: JVM treats default instance as 'null'
>
> Like Option G, an inline class file can indicate that its default instance
> is invalid—in this case, 'null'. All attempts to operate on that instance
> result in an NPE. Conceptually, the null instance and the null reference
> are the same, and should generally be indistinguishable.
>
> (We explored this awhile back as a tool for migration, before going in a
> different direction.)
>
> Some implications:
>
> - The VM probably wants to normalize its encodings (null reference vs.
> null instance), meaning there's a translation layer on field/array reads,
> just like Option I, and also for field/array writes, just like Option D.
>
> - Casts to Q types for certain classes should also translate from null
> reference to null instance, rather than NPE.
>
> - For these classes, the 'withfield' instruction is uniquely able to
> operate on and produce 'null'.
>
> - In the language, the 'null' literal can be assigned to some inline
> types. (In the VM, the verifier could require using 'defaultvalue' instead,
> if it wants to avoid some class loading.)
>
> - We could revisit the question of whether it's possible to migrate an
> identity class to be an inline-default inline class as long as the default
> instance is 'null'. (There are additional issues, like binary
> compatibility. But we could we-open that exploration...)
>
> ---
>
> My sense is that Option I dominates Option J by most measures—it achieves
> the same result (default value is invalid), with less work at flattened
> storage barriers, fewer tweaks to the rest of the system, and a more useful
> programming model (no nulls being passed around).
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com