Migrate from JSR-305

[alexander-yevsyukov]

There are several problems with this dependency:

• JSR-305 causes problems with Java 9 because it lives in the javax.annotation, which is also used by other modules.
• This JSR is long (2006) abandoned.
• The artifact that is being used was not released by the JSR committee. So, it's not really likely that we are going to have any updates to this code.

What our colleagues do about it

• Guava started migration to Error Prone and the Checker Framework in 23.6.
• Kotlin is going to address this issue (and one more).

[alexander-yevsyukov]

We mainly use Nullable and ParametersAreNonullByDefault from JSR-305.

Here are some links related to the matter:

• FieldsAreNonnullByDefault
• ReturnValuesAreNonnullByDefault
• EverythingIsNonnullByDefault

[alexander-yevsyukov]

Checker Framework release v2.1.14 mentions that:

Nullness Checker change to annotated JDK: The type argument to the Class, Constructor, and Optional classes may now be annotated as @nullable or @nonnull.

Who are those noble gentlemen?

[alexander-yevsyukov]

@armiol, comparing Checker Framework and SpotBugs (which is the successor to FindBugs), the former is much more actively developed.

[alexander-yevsyukov]

There's also lastNPE.org project associated with Eclipse.

[alexander-yevsyukov]

So far, assuming Guava's transition and other factors the Checker Framework is a winner for our migration.

We have Guava as the dependency anyway. Using the Checker Framework in our code would not increase dependencies.

[alexander-yevsyukov]

As we're migrating to Java 8, we need to use @Nullable instead of @NullableDecl. See the recent commit in Guava on this.

[alexander-yevsyukov]

Partially this issue is addressed by #109. By now, there is no replacement for ParametersAreNonnullByDefault. Although, it's relatively easy to create a replacement, let's wait till the issue is addressed by our colleagues in Guava.