Nullability in Java

Clement Cherlin ccherlin at gmail.com
Fri Oct 11 16:46:01 UTC 2024


Hello,

I did some more thinking and have clarified my responses.

On Wed, Oct 2, 2024 at 9:30 AM <forax at univ-mlv.fr> wrote:

> 1) If you have a code like:
>   String s = f();
>   g(s);

If 's' has its null-marker computed automatically, the null marker will
> flow naturally without the user having to update his code each time the
> API of a dependency is updated to use null-marker.


I don't follow. If I null-marked my code consistently, why would I need to
update it when my API dependencies change? On the other hand, if I marked
my code inconsistently with my API dependencies, then I probably need to
update my code, because my assumptions were incorrect!

2) until now, the type of a local variable would never change, we have even
> introduced the concept of binding to explicitly avoid a local variable to
> have its type changed.
> But we also want the nullability part of the type of a local to change
> dependending on the control flow, so having a way to denote the nullability
> on a local's type given that it can changed is weird.


To put my earlier comments much more succinctly, "nullability" is not the
same as "nullness". The nullability of a variable's type is always how it
is null-marked. Nullability does not change, regardless of control flow.

Nullness does change with control flow. Values of nullable types have
different nullness at different points in a program.

Declaring static nullability enhances dynamic nullness analysis and
helps detect bugs.

For that reason, we should allow and encourage null-marking local
variables.

Cheers,
Clement Cherlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20241011/b7133e40/attachment.htm>


More information about the valhalla-spec-observers mailing list