Suggestion regarding Null State Analysis in Project Valhalla

[David Alayachew]

Would it make sense to have separate semantics for method headers vs local
fields?

For method headers, ! = non-null, ? = null permitting, and the absence =
unspecified

But for local fields, have the absence have similar semantics to var, where
it derives the nullity information of a variable from the headers of the
methods that populated or updated the field.

That way, you should be able to avoid a massive chunk of the rewrite effort
-- you need to rework all your method headers, but much of the method
bodies can remain mostly untouched.

On Thu, Jun 12, 2025, 8:27 AM Remi Forax <forax at univ-mlv.fr> wrote:

> Hello Abdurasul,
>
> We know from people that have added annotations (jspecify or others) to
> big codebases that not having an unspecified state (or as you suggest
> having an unspecified state with warnings) generates too many warnings to
> the point developers find it a burden.
> I think the real answer is we will see once we first have a prototype.
>
> regards,
> Rémi
>
> ------------------------------
>
> *From: *"Brian Goetz" <brian.goetz at oracle.com>
> *To: *"valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> *Sent: *Thursday, June 12, 2025 1:55:19 PM
> *Subject: *Fwd: Suggestion regarding Null State Analysis in Project
> Valhalla
>
> Received on the -comments list.
>
> Begin forwarded message:
>
> *From: *Abdurasul Abduraimov <abdurasulabduraimov22 at gmail.com>
> *Subject: **Suggestion regarding Null State Analysis in Project Valhalla*
> *Date: *June 12, 2025 at 1:06:49 AM EDT
> *To: *valhalla-spec-comments at openjdk.org
>
> Dear Team,
>
> I am a big fan of Java and I’m eagerly awaiting the release of Project
> Valhalla. I watched the Valhalla session from IntelliJ IDEA Conf 2025 (Day
> 1), where Rémi Forax discussed the "Null State Analysis" feature. As he
> explained, the system defines three null states:
>
>    1.
>
>    *Null-restricted:* Integer! or String!
>    2.
>
>    *Nullable:* Integer? or String?
>    3.
>
>    *Unspecified:* Integer or String (with no warning)
>
> I understand that due to Java’s large amount of legacy code, introducing
> nullable and non-nullable types (as in Kotlin) is challenging, and the team
> is prioritizing backward compatibility.
>
> However, I’d like to propose an idea:
> What if the *Unspecified* state also emitted a warning? This way, all
> types would continue to be effectively nullable (as they are today), but
> developers upgrading to future Java versions (where Valhalla is finalized)
> would be encouraged to explicitly annotate their types. They could mark
> types as *not-null* where appropriate, or accept the nullable default,
> making their intentions clear.
>
> This would parallel Kotlin’s philosophy, but in an inverse way:
>
>    -
>
>    In Kotlin: all types are *not-null* by default, nullable types must be
>    explicitly declared.
>    -
>
>    In Java (with this proposal): all types would be *nullable* by
>    default, but *not-null* types would be explicitly declared — with the
>    added benefit of a warning to help modernize existing code.
>
> I know it’s a bit unusual, but I believe this approach could strike a
> balance between safety, clarity, and backward compatibility.
>
> Thank you for your great work on Java!
>
> Best regards,
> Abdurasul Abduraimov
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20250612/d02e3955/attachment-0001.htm>