Thank you for this PR, but the problem with this fix is that once the Mockito project has taken this problem into account, we'll still have a method that's of no use. Rather than bypassing the problem in JP, it would be better to insist that the Mockito project take this problem into account.

I agree on the principle that "it would be better to insist that the Mockito project take this problem into account". But at the current state of things, it seems to be a rather speculative argument:

• the issue is open since 2018 (6 years)
• a core developer of Mockito clearly stated that it is prone to stay like that4 years ago
• the issue is still open despite a strongly supported suggestion4 years ago too

In short, it looks like neither the Mockito team is willing to do it, nor any one in the open source community able to provide a satisfying solution for it after 6 years.

We could have argued that it was a niche issue having low attention, but it is not: any Mockito user faces it from the start, since mock() is a core method, used massively, and the warning comes as soon as we mock a generic class, which is rather frequent. So it is a systematic issue that still has no solution after 6 years, which is prone to support that it is a design flow that cannot be fixed easily.

I am a newbie in JavaParser, so it might be not a good comparison, but it makes me think about the LexicalPreservingPrinter and its limits in keeping the formatting also for inserted code. Even if someone "insisted" that the JavaParser project should take this problem into account, it does not look like it would solve itself.

If we discard the idea of getting anything from Mockito itself, then it comes down to what JavaParser would do. Here we speak about 100 warnings in GenericVisitorAdapterTest and 100 warnings in GenericListVisitorAdapterTest. I don't know how you managed to keep them at exactly 100 each, but good job! {^o^}

200 warnings is a lot, though. Enough to say that one or two more warnings won't change anything, which breaks the incentive to fix them at all. So it looks to me that if you don't do anything here, there is barely any point to fix any other warning, since we will remain with a lot of them anyway.

Given how trivial is your use of Mockito, I think that the proposed solution gives a rather compelling warning fix:

• it is quick and easy and covers all the unchecked warnings in the class,
• it still looks like we use Mockito directly, so it does not disrupt the current practices
• if Mockito happens to fix it, it will be easy to revert this change

There is other ways to make these warnings disappear, but this compromise seems the most reasonable to me.

By the way, if Mockito happens to fix it, it means that the@SuppressWarnings("unchecked") will be irrelevant, which will generate a warning on it. So you will quickly spot that the "unwanted" method should be fixed, then that the comment associated to it is not true anymore, and so remove it.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 51.967%. Comparing base(c3b7bdc) to head(a38936d).
Report is 3 commits behind head on master.

@@            Coverage Diff            @@##            master     #4413   +/-   ##=========================================  Coverage   51.967%   51.967%           =========================================  Files          505       505             Lines        28456     28456             Branches      4930      4930           =========================================  Hits         14788     14788             Misses       11616     11616             Partials      2052      2052

Please see#4408 for a guide on how to resolve the git conflicts with the recent reformatting.

@johannescoetzee what about new PRs? Do we need to execute./mvnw spotless:apply systematically to preserve formatting?