Annotation targets and retentions for nullness annotations

[kevin1e100]

We've talked about using runtime retention for annotations unless there's a good reason not to, I believe. For nullness at least we're also looking at a combination of type-use annotations, such as @Nullable, and declaration annotations, such as @DefaultNonNull. Filing this issue to point out a potential pitfall for reflective tools, specifically on Android:

Type-use annotations can't be encoded in Android apps, currently, so there's no way to do runtime reflection on them. On the other hand, reflection is possible with declaration annotations. That creates the potentially confusing situation that runtime libraries that use reflection, when run on Android, may "see" @DefaultNonNull surrounding a method but not @Nullable on the method's return type, for instance, so they may erroneously conclude that the return type is non-null.

This potential confusion could be avoided with class retention, but that prevents any reflection on nullness annotations, even outside Android, which also seems unfortunate.

I'm not sure we need to do anything here, but I wanted to file this away for posterity.

[cpovirk]

I agree that this is unfortunate -- hopefully only mildly so, especially since I don't see what we can do about it (other than giving up on runtime retention).

There isn't a way for us to ship a Proguard configuration that says to not keep a specific annotation, right? Or even if there is, that might be frowned upon, since the usual model is to specify what to keep, not what to remove.

One possible workaround in the long term is for users to declare their own alias for @DefaultNonNull, giving it only class retention.

[kevinb9n]

This seems like a dup of #28.

[cpovirk]

(The intention was that this issue would capture anything nullness-specific, like Kevin's comments about the absence of type-use annotations at runtime for Android. But I don't think there's been enough concern about that to leave this one open.)