Non-Nullable type syntax

[Brian Goetz]

This is a fair question, let me try to give a fair answer.

> Hi,
>
> This might be a ridiculous suggestion but why don't Java add a bang in the type declaration to indicate non-nullable and leave the current meaning nullable.

I don't want to use the word "ridiculous", but the reality is that 
picking a syntax for "non-nullable" is literally the first zero percent 
of the work.  And the size and cost of remaining work is not far from 
that of "adding generics to Java".  So it is doable, but it essentially 
would consume the entirety of the attention of the Java language team 
for years, not to mention a significant impact on Java developers to 
learn the new rules.  That is a lot.

If you were starting with a new language, working cardinalities (! means 
one, ? means zero or one, * means zero or more, etc) into the type 
system from day 1 is a reasonably well-understood concept, as other 
languages have demonstrated.   (The history of this started long before 
Kotlin.)  But grafting cardinalities onto an existing language with 
billions of lines of code extant -- in a way that is compatible with all 
the code out there, and which provides a gradual migration path from 
"old" to "new" code -- is an entirely different story, and for Java, 
would be a significant task, replete with uncomfortable compromises.

Language aside, there also is the matter of annotating the libraries (a 
problem akin to generifying libraries after Java 5.) Reconstructing the 
original design intent ("could this ever return null?") can be difficult 
to do if it is not captured initially, and presumably it is not a 
compatible move to, say, turn a parameter from T to T!.  Even if we left 
the old libraries alone (which would not be popular), we would have 
issues at the boundary of old libraries and new; if List::get returned a 
T, that becomes a friction point with new libraries that are expecting a 
T!.  Do we expect users to put in explicit casts at those points 
(intrusive), or support an implicit conversion that might NPE (akin to 
autoboxing)?  Both of those options are not great.

Essentially, this is not something we can do "a little bit"; we either 
have to do it all (which is a multi-year investment for a nontrivially 
sized team of world-class experts), or we shouldn't do anything.  
Otherwise, we risk this becoming a tease, where it looks like you get 
some benefit, but that benefit stays in an annoyingly small corner of 
the codebase.


> Like GraphQL schemas, and opposite to the Kotlin question mark.
>
> Obviously this wouldn't break anything existing and would allow for the same benefits the aforementioned languages have. Then everything could unify to this language construct, no need for the not universally used @Nullable nor Optional.
>
> Kind regards,
>
> Kye
>
> Sent from ProtonMail mobile