Manu Sridharan

As additional context [this](https://github.com/Kotlin/KEEP/blob/41091f1cc7045142181d8c89645059f4a15cc91a/proposals/jsr-305-custom-nullability-qualifiers.md) is how Kotlin interprets nullability annotations from Java libraries. We might want to eventually do something similar

I can't reproduce this on NullAway master, which tests against Error Prone 2.14.0. Could you see if you still observe a crash with the latest Error Prone release?

Going to close this out but if you can repro with latest release let us know

This is correct. Currently NullAway has no special support for generic types. See #54 for some initial ideas for how we could add some support for checking clients of generic...

I don't think we've run into a situation where we had to annotate a library like Guava, with so many generic collection classes. We do have some internal generic collection...

Proper support for generics in the presence of subtyping is fairly non-trivial. Plus I really do not want to compromise the performance of NullAway on non-generic code, so some care...

TCF's nullness checker is far more powerful (and sound) than NullAway. The framework is also general and not specialized to nullness checking, which probably has a performance cost. I think...

@kageiit my concern is that users of an annotated generic library get sensible behavior from NullAway no matter the configuration. Users may be confused if they need to opt in...

> In TCF, a type parameter that has no annotations is assumed to have a nullable upper bound. For example, > interface List { > T add(T t); > }...

@chengniansun ok, the CF nullness type system is a bit complex :smile: I think a brief summary is that if you just have `class Foo`, then a client can write...