Retrofit: Evaluate a nullable static analysis library

Created on 7 Oct 2014 · 9Comments · Source: square/retrofit

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

Source

JakeWharton

Most helpful comment

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.

JakeWharton on 7 Dec 2016

👍2

All 9 comments

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

JakeWharton on 5 Jun 2015

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?

joshfriend on 29 Nov 2016

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.

JakeWharton on 7 Dec 2016

👍2

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.

swankjesse on 7 Dec 2016

👍1

Then you might want to use @ParametersAreNonnullByDefault

vanniktech on 7 Dec 2016

@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

joshfriend on 7 Dec 2016

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