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" <[email protected]> > To: "valhalla-spec-experts" <[email protected]> > 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:[email protected] | >> [email protected] ] > >> Subject: Suggestion regarding Null State Analysis in Project Valhalla >> Date: June 12, 2025 at 1:06:49 AM EDT >> To: [ mailto:[email protected] | >> [email protected] ] >> 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
