Suggestion regarding Null State Analysis in Project Valhalla

[Remi Forax]

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 < [ mailto:abdurasulabduraimov22 at gmail.com |
>> abdurasulabduraimov22 at gmail.com ] >
>> Subject: Suggestion regarding Null State Analysis in Project Valhalla
>> Date: June 12, 2025 at 1:06:49 AM EDT
>> To: [ mailto:valhalla-spec-comments at openjdk.org |
>> 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-experts/attachments/20250612/c6282f83/attachment.htm>