Nikolay> annotation that doesn’t add any value to the code is a bad thing
It is really sad to hear "doesn't add any value".
Nullability annotations detect bugs, they make coding easier (IDE
understands nullability),
it makes the intention behind method signatures easier to understand.
Nikolay>Java is known as a very verbose programming language, so making it
even more verbose
Thanks for bringing this point.
I had exactly the same question/feeling at the very beginning.
In practice, it turned out that null-heavy code is harder to work with in
Java.
In other words, if the code has limited use of nulls, then it is easier to
read and reason about.
At the same time, the number of @Nullable entries is low.
For instance, 865 files have at least one occurrence of @Nullable.
304 of them have exactly one line with @Nullable
142 files use @Nullable just two times
In total, 768 files (~90%) have less than 10 lines with @Nullable.
That is yet another way to highlight that @Nullable does not make the code
much more verbose.
a) Java's verbosity is one of its powers. Once you open a declaration, you
see what it means
Let me quote a sample constructor from Sort class:
/**
* Creates a Sort.
*
* @param cluster Cluster this relational expression belongs to
* @param traits Traits
* @param child input relational expression
* @param collation array of sort specifications
* @param offset Expression for number of rows to discard before
returning
* first row
* @param fetch Expression for number of rows to fetch
*/
protected Sort(
RelOptCluster cluster,
RelTraitSet traits,
RelNode child,
RelCollation collation,
@Nullable RexNode offset,
@Nullable RexNode fetch) {
super(cluster, traits, child);
this.collation = collation;
this.offset = offset;
this.fetch = fetch;
@Nullable annotations make it immediately visible that offset and fetch can
be nullable.
Of course, it would be great if we could document special values (e.g. what
fetch=null means),
however, we have no way to enforce a policy to make all javadocs meaningful.
In practice, we do not even enforce javadocs since global enforcement would
result in lots of time spent on writing "Returns x. @return x"
documentation for "int getX()" methods.
b) Nullable annotations enable IDE to better understand the code and
highlight defects before you even compile the code.
For instance, if you pass null argument to a non-nullable parameter, then
IDE would show a warning.
c) Nullable annotations improve integrations with languages that have
stronger null safety.
As you might know, Kotlin, Swift, Dart, and others bake null-safety right
into the type system of the language.
If we keep the API null-safe (annotate nullable types), then the API would
be way easier for the consumers.
Vladimir
