Choose non-null annotation name

[jspecify]

Choose non-null annotation name

[kevinb9n]

I don't think I've really heard anyone else but me championing @NotNull, so unless that changes rapidly we should indeed adopt @NonNull (as long as, please, it's cased like that). [edit: then, amusingly, github changed the casing I wrote. Fixed now.]

Among existing such annotations, clearly that name is not just slightly more common than the others, but dramatically so.

[kevinb9n]

Just a minor note that if #230 goes yes, there is some slight potential to find a substantially different name that better suggests "this isn't the useful thing you imagine it is", and that could reopen this.

I'd moderately insist we never go back to non-vs-not though :-)

[kevinb9n]

I think that "non-nullable" and "not nullable" are equally valid adjective phrases.

Why I like NotNull: Going with "non" requires a fairly arbitrary choice about whether to capitalize the next letter which will be hard for all users to remember. I also think "non-null" is a little awkward phonetically and "not null" is crisp and clear.

[donnerpeter]

Great, thanks! Unless other native speakers have different opinions I'm fine with @NotNull

[cpovirk]

I continue to like the idea of largely sidestepping this issue by leaving @NotNull / @NonNull / @Nonnull / @NotNullable out :) (#4)

That does still leave the @Default... version of the annotation, but maybe it's easier to stomach "the default is not null" (@DefaultNotNull) than "a string that is not null" (@NotNull String)?

[edit: Thanks, @wmdietlGC, for catching my typo in the number of the issue I was trying to link to]

[wmdietlGC]

@cpovirk I think you meant to refer to #4 not #40.

I have gotten used to @NonNull and as @stephan-herrmann points out in #53 it reads nicer in type-argument positions.

[amaembo]

Well, JetBrains annotations use @NotNull, so we get used to it, but probably we are the outsider here. At least here's the list of annotations IDEA recognizes by default:

  static final String[] DEFAULT_NOT_NULLS = {
    "org.jetbrains.annotations.NotNull",
    "javax.annotation.Nonnull",
    "edu.umd.cs.findbugs.annotations.NonNull",
    "android.support.annotation.NonNull",
    "androidx.annotation.NonNull",
    "androidx.annotation.RecentlyNonNull",
    "org.checkerframework.checker.nullness.qual.NonNull",
    "org.checkerframework.checker.nullness.compatqual.NonNullDecl",
    "org.checkerframework.checker.nullness.compatqual.NonNullType",
    "com.android.annotations.NonNull",
  };

[wmdietlGC]

For reference, the list of aliases used by the Checker Framework, from https://github.com/typetools/checker-framework/blob/master/checker/src/main/java/org/checkerframework/checker/nullness/NullnessAnnotatedTypeFactory.java#L94 :

private static final List<String> NONNULL_ALIASES =
  Arrays.asList(
    // https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/annotation/NonNull.java
    "android.annotation.NonNull",
    // https://android.googlesource.com/platform/frameworks/support/+/master/annotations/src/main/java/android/support/annotation/NonNull.java
    "android.support.annotation.NonNull",
    // https://android.googlesource.com/platform/frameworks/support/+/master/annotations/src/main/java/androidx/annotation/NonNull.java
    "androidx.annotation.NonNull",
    // https://android.googlesource.com/platform/tools/metalava/+/master/stub-annotations/src/main/java/androidx/annotation/RecentlyNonNull.java
    "androidx.annotation.RecentlyNonNull",
    "com.sun.istack.internal.NotNull",
    // http://findbugs.sourceforge.net/api/edu/umd/cs/findbugs/annotations/NonNull.html
    "edu.umd.cs.findbugs.annotations.NonNull",
    // https://github.com/ReactiveX/RxJava/blob/2.x/src/main/java/io/reactivex/annotations/NonNull.java
    "io.reactivex.annotations.NonNull",
    // https://jcp.org/en/jsr/detail?id=305
    "javax.annotation.Nonnull",
    // https://javaee.github.io/javaee-spec/javadocs/javax/validation/constraints/NotNull.html
    "javax.validation.constraints.NotNull",
    // https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/NonNull.java
    "lombok.NonNull",
    // https://search.maven.org/search?q=a:checker-compat-qual
    "org.checkerframework.checker.nullness.compatqual.NonNullDecl",
    "org.checkerframework.checker.nullness.compatqual.NonNullType",
    // https://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/annotation/NonNull.html
    "org.eclipse.jdt.annotation.NonNull",
    // https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit/src/org/eclipse/jgit/annotations/NonNull.java
    "org.eclipse.jgit.annotations.NonNull",
    // https://github.com/JetBrains/intellij-community/blob/master/platform/annotations/java8/src/org/jetbrains/annotations/NotNull.java
    "org.jetbrains.annotations.NotNull",
    // http://svn.code.sf.net/p/jmlspecs/code/JMLAnnotations/trunk/src/org/jmlspecs/annotation/Nullable.java
    "org.jmlspecs.annotation.NonNull",
    // http://bits.netbeans.org/8.2/javadoc/org-netbeans-api-annotations-common/org/netbeans/api/annotations/common/NonNull.html
    "org.netbeans.api.annotations.common.NonNull",
    // https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/lang/NonNull.java
    "org.springframework.lang.NonNull");

[kevinb9n]

noN is clearly more popular, though the fact not everyone agrees on its casing is one of the main things I dislike about it.
Oh, and here's a fun thing: the importance of our picking the name that most people guess is that if we don't, their IDE might just seamlessly grab one of the others still sitting around on the classpath and happily keep on going. (I wonder what present or future IDE features could prevent that.)

[kevinb9n]

(When we summarize these debate points, reminder to pull out Stephan's arguments in #53.)

[amaembo]

I wonder what present or future IDE features could prevent that.

Sure in future IDE could check a classpath and if there are CA annotations available we may warn on the usage of any other annotation and suggest the replacement (ugh, at least in the places where semantics is the same).

[stephan-herrmann]

As the author of one of the @NonNull annotations, I'm ready to admit that "nonnull" seems to be an accepted English word (found in several online dictionaries), so no hyphen nor camel case is needed. => Proposing @Nonnull going forward.

[kevinb9n]

"nonnull" may be legal, but would we actually use it in our documentation prose? I don't see any benefit to it. But we could go either way, and likewise would go either way with the annotation spelling. I'll just say again that this is arguably reason enough to prefer @NotNull.

I also, maybe it's just me, but when I look at @Nonnull it kinda makes my eyes swim. Too many double letters! (I concede I may be overly traumatized by the "too many double letters" issue for my own reasons :-))

[kevinb9n]

Adding to that: I feel fairly certain we would never write "nonnullable" in prose, only "non-nullable", which suggests we will also write "non-null" in preference to "nonnull".

We haven't discussed which style guide to adopt, but if it's Google Style, it dictates @NonNull over @Nonnull in that event.

There are also these well-known library precedents: Guava went with the method name Preconditions.checkNotNull, and Java SE years later went with Objects.requireNonNull. (The fact the latter is the one built into Java is an argument for Non vs Not.)

[mernst]

I prefer @NonNull.

Versus @NotNull: In English, we speak of a "non-null reference", not a "not-null reference". That is, "non-null" reads well as an adjective but "not-null" does not. Naming type qualifiers like adjectives improves code readability.

Versus @Nonnull: I typically write "non-null" rather than "nonnull", because it reads better to me. I admit this is purely subjective.

Finally, @NonNull seems to be the most popular in other projects.

(Others made similar points already. Maybe we are ready to make a decision?)

[kevinb9n]

updated references in key docs.

[cpovirk]

Today at Google, some of us will be discussing potential replacement names for @CheckReturnValue and @CanIgnoreReturnValue. One thing I notice is that we seem to prefer "not" over "non" in that context.

Given that...

I'd moderately insist we never go back to non-vs-not though :-)

...the best possible outcome is probably for us to decide that we like some names that don't have "not"/"non" in them at all :)

Still, @CheckReturnValue is unlikely to be the last "domain" in which "not"/"non" comes up: It's now come up in 2 of 2 domains, and one could at least imagine a @NotFinal/@NonFinal debate someday.

I think I'm still happy with "@NonNull" as a name, but it will be a little said if we end up with @NonSomething and @NotSomethingElse a decade from now.

[Update: We ended up not getting far enough to discuss "non" and "not." I'll try to remember to update whenever we come back to that.]