Idle thought:

Just as some users want lenient/permissive treatment of the Object parameters of collection types, which is now available through collection-object-parameters-may-be-null.astub, some users want such treatment of the parameters of java.lang.reflect APIs like Method.invoke, Field.get, Field.set, Constructor.newInstance, and arguably more exotic APIs like those on AtomicReferenceFieldUpdater. (I've seen requests for some of these methods both inside Google and in this issue tracker.)

Background for anyone reading this who doesn't already know it: There are 2 kinds of parameters that are relevant here:

• Some methods have a "receiver" parameter, which can safely be null if and only if the method/field is static.
• All methods have "method parameter" or "field value" parameters, which can safely be null if and only if the corresponding underlying method parameter or field is nullable.

Anyway: I don't know how far you want to go down the road of providing such astub files. I can imagine at least two other astub files that users might request offhand (for which I could file separate issues if you're interested):

• Some users want to allow @Nullable Optional.
• Some users want for Object.requireNonNull to tolerate null inputs.

I'm not sure where to draw the line. If I were to make a case for an astub file for the reflection methods specifically, I would argue that the reflection methods can always be used to violate null safety no matter how we annotate them, just as they can be used to violate Java's own type system. For example, we can't stop users from calling method.invoke(receiver, Arrays.asList(null)) (that is, from passing a List<@Nullable Object>) when the method requires a List<@NonNull Object>. I'm not sure there's a way to avoid that, short of checking all parameters to the reflection methods to ensure that none have parameterized supertypes.

(Aside: I should see how well -AresolveReflection works for the cases in which I've had to suppress warnings....)