Dependency for @NonNull annotation

[Ryan Nett]

I'm working on adding @NonNull/@Nullable annotations, primarily for Kotlin interop.  There's a few choices of where to get it from:

• JetBrains (@Nullable and @NotNull from the org.jetbrains.annotations package)
• Android (com.android.annotations and android.support.annotations)
• JSR-305 (javax.annotation, more details below)
• FindBugs (edu.umd.cs.findbugs.annotations)
• Eclipse (org.eclipse.jdt.annotation)
• Lombok (lombok.NonNull).

See https://stackoverflow.com/questions/35892063/which-nonnull-java-annotation-to-use and https://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use.

Generally, I'd default to javax.annotation, probably from com.google.code.findbugs:jsr305.  However,  the JSR is stale, and the annotation isn't a type annotation.

Unless we're planning on adding a bug checker, JetBrains seems like the best after that, since Eclipse's NonNullByDefault does nothing for Kotlin.

JSpecify seems like it will eventually be the solution for things like this, but as far as I know it's still in development.

Of course, this depends on the dependency policy, which has yet to be decided on, but does anyone have preferences for which dependencies to look at?

[Adam Pocock]

Does Kotlin support Checker Framework?

I'd prefer not to use anything that implies a different runtime or compiler, which rules out Android & Eclipse respectively. JSR-305 causes module issues and that seems like a bad idea. FindBugs isn't maintained, and Lombok brings a large pile of other stuff that I don't think is a good idea to have.

So I guess that leaves the JetBrains ones, which have the benefit of being a single library, but I still feel a bit uncomfortable depending on a particular tooling vendor.

I wish JSpecify would hurry up, but I've not seen anything from them since the JVMLS 2019 talk. Though at least they finally put the slides for that talk up.

That said, I'd still prefer to have no dependencies in the core library, but I understand that causes problems for Kotlin.

Adam

[Ryan Nett]

It does, but from what I saw that adds a lot of stuff that we may not want in core, and I never found a clear answer if you could use it without it's custom javac.

I saw this answer that claims JSR-305 should work fine with modules, but we should probably test it if we do end up using it.

The full list of supported annotations is here: https://github.com/JetBrains/kotlin/blob/master/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/JvmAnnotationNames.kt

I'd be more warry of JetBrains if this wasn't mostly for Kotlin support, but as it is I don't see any other good options.

[Adam Pocock]

I think that says it works fine with JSR-305 assuming you don't actually want to use any Java EE stuff on the module path as well, at which point it will conflict. Though given Jakarta EE 9 renamed all the modules that's a legacy issue.

Looks like the checker-qual jar is standalone and also under an MIT license, but I didn't realise the checker framework itself was under a GPL 2 license, so that's probably going to involve legal complications which we should avoid.

Thanks,

Adam