Migrate JMockit block to Mockito which contains redundant "this" prefix for arg matcher and migrate array as parameter for any

[yurii-yu]

What's changed?

Be able to cope with corner cases in refactoring JMockit Verifications.

1. Normally, anyString in JMockit should be refactored to anyString() in Mockito, so as to anyInt or anyLong. But when there are redundant this before anyString, the code will not be processed because OpenWrite treat anyString as an J.Identifier object where as this.anyString as a J.FieldAccess object. My patch will do a type cast for this exact case.
2. Normally, (Object) any in Mockito should be refactored to any(Object.class) in Mockito. This works for simple Object. But when Object is an array such as (byte[]) any, OpenRewrite will not change it to any(byte[].class) because the class type of byte[] is not JavaType.FullyQualified. I added processing branch for this case.

Corresponding unit tests were also added.

What's your motivation?

We encountered problem in dealing with several legacy projects.
Some codes can not be refactored automatically, while manually changing them seems tedious, since they are not complex at all. We located and solved this problem, which can save us quite a lot of time.
Benefited a lot from the OpenRewrite project previously, we believe that more people and more legacy projects should be able to take advantage of it.

Anything in particular you'd like reviewers to focus on?

My solution for the second question is obviously not the perfect one, because the element type of array could be another array so theoretically this could be a infinite loop. Solving such problem will take me much more time and energy.
But I guess that is a rare case which is almost impossible to encounter, so my code simply assume that the element type of the array is plain object.

Anyone you would like to review specifically?

@timtebeek Please have a look again on my code, amigo :)

Have you considered any alternatives or workarounds?

Yes, as I mentioned above, I think a perfect solution for the second question is unworthy.

Any additional context

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Many thanks for the continued improvements here! I'm traveling right now so it's a bit harder to do a detailed review. Perhaps @shivanisky can chime in? (No requirement of course!)
Otherwise I should be back Monday, for one day only, and can try to fit it in then.

[shivanisky]

Many thanks for the continued improvements here! I'm traveling right now so it's a bit harder to do a detailed review. Perhaps @shivanisky can chime in? (No requirement of course!)

Otherwise I should be back Monday, for one day only, and can try to fit it in then.

Weekend is looking busy but I'll try to look if I get free. Glad to see this work is helping ☺️ others.

These code changes affect not just JMockit Verifications but Expectations and NonStrictExpectations migration as well, essentially the entire JMockit to Mockito migration.

[yurii-yu]

@timtebeek Could you please kindly have a look at this pull-request? Thank you.

[timtebeek]

Thanks a lot for these fixes @yurii-yu ! Good to have those this. cases covered as well, and thanks for the help reviewing @shivanisky 🙏🏻