Strangeness with generics and callbacks. about jspecify HOT 7 CLOSED

👍 https://youtrack.jetbrains.com/issue/IDEA-341808/T-extends-Nullable-Object-should-not-always-be-treated-as-nullable.

from jspecify.

I agree with @cpovirk . Ironically given how well IntelliJ does so many other things I have found it to be lacking on null analysis when it comes to generics and when I went code diving trying to figure out how it worked it appears to be far different than the others.

When I have run into this issue usually with Streams is that Checker is the only one that seems to get it consistently right but I'm haven't been using the reference checker lately.

Eclipse needs the type witness notation for some reason that I think Stephan explained to me in a chat room once. I will check with them after the holidays to find out why or what is the limitations.

Across my projects I plan on adding null analysis using each tool in my CI pipeline. I am currently missing IntelliJ (I just found out last year you can run its check stuff headless), and JSpecify reference checker. My hope is to somehow codify it into a Github action (one for maven and one for gradle... might not even just be put this Maven profile in your script etc) for library authors to quickly play with the various frameworks and to find inconsistencies.

from jspecify.

For most frameworks you need to use the type witness notation because it can't properly deduce from the left hand.

I did not test your case on IntelliJ but Eclipse null analysis will do the same thing.

To fix it you would do something like:

JsonDecoder.<Integer>field(....);

from jspecify.

That does not seem to work in this case

from jspecify.

Yes but intellij null analysis isn’t really type based last time I checked.

Eclipse and Checker are. Try those guys.

Check out this action I use that tests with both: https://github.com/jstachio/jstachio/actions/workflows/analyze.yml

from jspecify.

Your understanding of the meaning of the code looks correct to me, as well. I, too, would expect the Checker Framework and our reference checker to get this correct (though no guarantees :)), likely including without the explicit type argument. I haven't used Eclipse enough to predict how it would behave, but I would not be surprised to see it work, either.

While IntelliJ (IIRC) can understand generics in some case (e.g., Future<@Nullable String>.get(), maybe?), this looks like a case I remember from testing IntelliJ on Guava: It's been a few years, but I think I was seeing T extends @Nullable Object lead IntelilJ to treat all usages of T as if they might be nullable, without regard to substitution.

The IntelliJ folks fixed some of the problems we reported with Guava. But given that Guava is a much heavier user of generics than the average project, they didn't try to deal with everything that came up frequently for us. (Not to mention that full handling of generics is quite a pain to implement.)

I'd encourage you to file an IntelliJ bug. Even if it doesn't get a quick fix, it should help to start establishing how often "real users" encounter some of the remaining issues in IntelliJ's support.

from jspecify.

Is this issue closeable now?

from jspecify.