<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Yes, this is something we have considered in quite some depth. Sometimes people refer to this as “The flippening”.
<div>The benefit of such a scheme is that null restricted is a better default, and the annotation burden of annotating a code base, old or new, much much lower. This is not small. But the downside is immense. </div>
<div><br>
</div>
<div>The downside is that it would be an incompatibility that is orders of magnitude bigger than anything we’ve contemplated before. What it would do is fork the language in two, which violates a key Java principle: “one language with the same meaning everywhere.”
The same goes with all the different flavors of this proposal - “new class”, @LanguageLevel, etc. They share the same characteristic that they want to retroactively redefine the meaning of existing Java source code.</div>
<div><br>
</div>
<div>People like to think this is a clever hack, but in reality would be the biggest philosophical change we’ve ever made. It’s not something we would consider lightly — and not something we will consider at all until after the current round of Valhalla JEPS
are completed. </div>
<div>
<div><br id="lineBreakAtBeginningOfSignature">
<div dir="ltr">Sent from my iPad</div>
<div dir="ltr"><br>
<blockquote type="cite">On Apr 10, 2025, at 9:53 AM, Jonathan F <livedinsquares@gmail.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"><style>body { font-family: Helvetica, Arial; font-size: 13px; }</style>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px;line-height:auto">
It seems the syntax of nullable types is extra-important for its usability, so here’s an idea which perhaps the EG hasn’t considered. Remi has mentioned a 2-states model? - maybe this is different:<br>
</div>
<div><br>
</div>
<div>- Assume there’s some way (any way) to specify default nullability within some scope: to set either that String means String!, or that it means String?. If you don’t specify anything, as now, String means unspecified null.</div>
<div><br>
</div>
<div>- Then: if you set default nullability to ! , you’re allowed to write String or String? but not String! (i.e. you can’t belabour the non-nullability of a particular String)</div>
<div><br>
</div>
<div>- Likewise if you set default nullability to ? , you’re allowed to write String or String! but not String?. Or maybe we don’t even need this default.</div>
<div><br>
</div>
<div>- (I think…) if you don’t set a default so it's 'unspecified null’ (as now), then neither String? nor String! is allowed: they force you to set a default.</div>
<div><br>
</div>
<div><br>
</div>
<div>The point of this is:<br>
</div>
<div><br>
</div>
<div>- There’s clarity in only being allowed to use 1 type of punctuation in a class. And seeing it tells you there’s a default.</div>
<div><br>
</div>
<div>- If you see ? or ! in a sample of code you’ll know what a bare String means: ’the opposite'.</div>
<div><br>
</div>
<div>- Pasting raw code between two classes with different nullability will often give compile errors from mixed punctuation (unless your IDE adjusts the code, which hopefully IDEs will).</div>
<div><br>
</div>
<div>- This fits with simple ways to convert an existing class to being null-aware: set the default to !, so existing types are reinterpreted as null-restricted, then fix errors by adding ? piecemeal. But if you want to make minimal changes you may want to
set the default to ? instead, then add ! piecemeal; or again maybe we don’t need that default - even simpler.<br>
</div>
<div><br>
</div>
<div>As for actually using ‘unspecified null’ (which I hope will be rare in null-aware code) - maybe String* or even String!? is OK.</div>
<div><br>
</div>
<div>I hope that (or something like it) makes sense.</div>
<div><br>
</div>
<div>Jonathan<br>
</div>
<div><br>
</div>
<div>Jonathan Finn</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>