Feedback on Null-Restricted and Nullable Types

[Enrique]

REF: https://openjdk.org/jeps/8303099

Feedback 1:

Using the syntax "Foo?" for nullables values does not discourage the
use of nulls in code.

In my experience working with Kotlin, novice (and not so novice)
developers just find themselves comfortable enough adding an extra
character and continue to infest code with nulls.

The syntax to use null must be "disgusting enough" in order to
discourage people from using it.

For example something like Foo!!!NullBackwardCompliant!!!. This syntax
is ugly enough to scare people about using it.


Feedback 2:
Most people naively tends to use null in next scenarios:

* A class/record must be initialized, but due to the data flow, some
of its members are not yet known in "present time". They depend on
future input data/processing.
* Some member must not take any value in a given context.

Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
Apply) values in parallel to null. Any read must throw a
FuturePointerException or NAPointerException.
While the behaviour looks similar to the current null and
NullPointerException, it makes error debugging much easier to
understand:
* A FuturePointerException promptly warns about some race condition:
Some code tried to read a value before some process (maybe another
thread) initialized it.
* A NAPointerException promptly warns about some error in the business
logic. Some code didn't contemplate the NA scenario.

"catch" blocks will also be able to make much more sensible decisions
(when compared to the pervert NullPointerException).

Without any JVM extension, a compiler most probably can automate a
similar behavior with a syntax similar to:

var Foo1 = Future
var Foo2 = NA

 Foo1 and Foo2 are **NOT** nullables.

  Foo2 becomes a constant (It will never change once defined and the
compiler can make many verifications out of the box).

  Foo1 must never be read until a given value is provided (after which
it will probably become constant).


My two cents!

Enrique Arizón Benito
Software Gardener