Evaluate a nullable static analysis library

[JakeWharton]

In general, the disparate nature of these tools depress me. It would be nice to have something assisting with this, however.

[JakeWharton]

Can't get on board with any, sadly. Too much fragmentation in this area.

[joshfriend]

I've tried to guess why each of the supported nullablilty annotations supported by Kotlin wont work:

• The AOSP/Android support annotations are obviously out since Retrofit is not an Android-only project
• JSR305 is marked as "Dormant" (read: dead?)
• IDE Specific annotations (org.eclipse.annotations) not available everywhere
• CheckerFramework/FindBugs are relatively heavy dependencies for what you would use them for

org.jetbrains.annotations however consists solely of 4 annotations (Mutable, Nullable, NonNull, and ReadOnly) and is available as a self contained dependency (#604 did not explain why they were not usable either)

Could you explain what you found when you investigated this which prevents using Kotlin's org.jetbrains annotations?

[JakeWharton]

You nailed most of the reasoning, yep!

The JetBrains ones are okay. We've actually used them in the past. Now that they're fixing their mistake of bundling them inside Kotlin instead of just depending on them they're even more appealing.

I'll bring this up with @swankjesse and see if we can't decide on one because it would likely apply to all our Java projects, not just this one.

[swankjesse]

I think I’m ready for this. I generally prefer JSR 305 but not well-motivated. JetBrains’ annotations seem reasonable.

Can we assume everything not-annotated is non-null? I’d like to make non-null our default if the tools will honor that.

[vanniktech]

Then you might want to use @ParametersAreNonnullByDefault

[joshfriend]

@vanniktech kotlin does not seem to support @ParametersAreNonnullByDefault at the moment, as noted in a similar issue for OkHttp: https://github.com/square/okhttp/pull/2969#issuecomment-259974936

[trevjonez]

If you do go with jetbrains for this task, It is worth noting that they have two different versions (org.jetbrains:annotations-java5 and org.jetbrains:annotations) and could cause hell downstream for people using the opposite of the one you select.

It gives further credence to the interop policy square has been using.

Also the java8 version of it currently breaks autovalue

[joshfriend]

WIP using org.jetbrains:annotations-java5: #2290

[JakeWharton]

2315