Referenced method returns @Nullable, but functional interface method java.util.function.Function.apply(T) returns @NonNull

[daniel-b2c2]

How does one satisfy NullAway here:

public interface RedisCache {
...
    @Nullable
    <T> Map<String, T> hgetall(CachedKey key);
...
}

...

public class Example {
   private final Function<RedisCache.CachedKey, Map<String, String>> retrieveFn;
   ...
   public Example() {
      retrieveFn = redisCache::hgetall;     // <<<<<<<<<<<<
   }

Example.java error: [NullAway] referenced method returns @Nullable, but functional interface method java.util.function.Function.apply(T) returns @NonNull
            retrieveFn = redisCache::hgetall;
                         ^

[msridhar]

Hi @daniel-b2c2 supporting this case requires support for writing @Nullable on generic type arguments. Out of the box NullAway does not support this. We are working on adding such support via JSpecify mode (docs). If you enable that, you should be able to write:

public class Example {
   private final Function<RedisCache.CachedKey, @Nullable Map<String, String>> retrieveFn;
   ...
   public Example() {
      retrieveFn = redisCache::hgetall;     // <<<<<<<<<<<<
   }

But, JSpecify mode support is a WIP, so you may run into other bugs. If you have time to give it a try, let us know. As an alternative, you can suppress the warning.

I'll close this out but if you have further questions please let us know.

[daniel-b2c2]

@msridhar sorry for the late response.

I see, do I understand correctly, that JSpecify mode is a mode of operation where NullAway will attempt to apply reasoning based on the JSpecify specification, as opposed to using its own 'internal nullaway' 'engine'/'rules'?

So if I enable JSpecify mode I may see errors that were not there before, while using nullaway?

Asking because a recent guava update where they've switched annotations to use jspecify seems to have created a fresh set of coding errors when using nullaway.

Further to this I saw a new version of nullaway, and I'm also finding new 'bugs' here too.

I will probably just surpress the warnings for now until JSpecify becomes stable.

[msridhar]

I see, do I understand correctly, that JSpecify mode is a mode of operation where NullAway will attempt to apply reasoning based on the JSpecify specification, as opposed to using its own 'internal nullaway' 'engine'/'rules'?

Basically, JSpecify mode adds support for checking generic types and other features that NullAway didn't support before. Since it's a large, risky change, and still incomplete, it's not enabled by default yet.

So if I enable JSpecify mode I may see errors that were not there before, while using nullaway?

Correct. But, as you've observed, with generics, it may enable you to get rid of errors that required a suppression when running without JSpecify mode. Unfortunately there isn't a clear winner at this point.

Asking because a recent guava update where they've switched annotations to use jspecify seems to have created a fresh set of coding errors when using nullaway.

We need to document this; in fact I opened #1193 on it. My recommendation is to try JSpecify mode to see how it works for you. I expect if there are false positives, they will be due mostly to #1075, and you can either suppress or (for now) add explicit type annotations to work around. You can feel free to report any other false warnings you run into. But overall, if you're a heavy Guava user, JSpecify mode may work better for you. FWIW, NullAway already being used successfully in JSpecify mode by some major projects like Caffeine. You can just expect possibly more churn in errors as you bump NullAway versions (including more true warnings).

I hope that helps. Please let me know if you have more questions.