Nullability of primitive types

Gernot Neppert mcnepp02 at googlemail.com
Thu Nov 4 08:03:23 UTC 2021


Dear experts,

regarding the ongoing debate about nullability of primitive classes:

even though we are talking about nullable vs. non-nullable _types_,
wouldn't it help to focus on null-permitting _usecases_?
There are class-members, method arguments and return-values of
primitive-class types.
IMHO, it would make real sense to defer the decision of permitting nulls to
each of these use-sites.

The "nullability" would be represented at each _use-site_ by the
corresponding Descriptor (L vs. Q) in the class-file,
and the _default_ would (obviously) be "L" for normal classes, and "Q" for
primitive classes.

Given a primitve class java.util.Complex,

the descriptor for a class-member declared "Complex number;" would be
"Qjava.util.Complex;"

wheras the descriptor for a class-member declared "@Nullable Complex
number;" would be "Ljava.util.Complex;"

Likeweise for method-signatures.

That way, there'd be no need to have two different class-mirrors for a
primitive class.
Of course, you would be able to query the "nullability" of a
java.lang.reflect.Field or a java.lang.reflect.Parameter via Core
reflection.
However, the API for obtaining java.lang.reflect.Methods would not need to
be changed at all!
Two methods whose signature only differed by "nullability" (aka L vs Q
signature) would be considered the same, thus the following would not be
allowed:

class ComplexCalculator {
  Complex add(Complex one, Complex two);

  @Nullable Complex add(@Nullable Complex one, @Nullable Complex two);
}

As for migration of existing none-primitive classes to primitive ones, it
would be possible to make @Nullable the default _usecase_ for a primitive
class:

@Nullable primitive class Optional<T> {
}

Then, for orthogonality, there'd be a means of specifying "Use this
primitive type as a non-nullable value here", maybe something like

@ByValue Optional<String> getName();

(As a sidenote, maybe a good name instead of @Nullable would be @ByRef).

And yes, with this proposal the Java primitive types (int, long...) would
remain special cases, and they would continue to have their "companion"
reference-types.


More information about the valhalla-spec-comments mailing list