Refactor instance based utility classes to static utility classes

The internal implementation of Mockito contains numerous helper classed that serve as a container for useful methods. By its nature these classes don’t have a state. Currently some them are instance based in other word you need to create the utility class to call a helper method. This not only pollutes the heap but also the code cause instance methods can’t be imported statically.

Here is an example:

Helper helper = new Helper();
if (helper.isInputValid(input)){
  [...] 
}

vs. static import of Helper.isInputValid

if (isInputValid(input)){
  [...] 
}

The aim of this ticket is to identify canidates that can be refactored to static utility classes. If you like to refactoring and mockito feel free to send a PR and reference this issue.

Refactoring canidates:

• AccessibilityChanger
• BeanPropertySetter
• ConditionalStackTraceFilter
• FieldCopier
• FieldReader
• GenericMaster should be integrate into GenericTypeResolver
• JUnitFailureHacker can be removed when the deprecated VerboseMockitoJUnitRunner is removed
• LenientCopyTool
• MatcherBinder
• MockitoCore should better be a singleton
• MockCreationValidator
• RemoveFirstLine
• #591 ArgumentMatchingTool
• #515 AllInvocationsFinder
• #502 ArgumentsComparator
• #540 ArrayUtils
• #490 AtLeastXNumberOfInvocationsChecker
• #490 AtLeastXNumberOfInvocationsInOrderChecker
• #912 Constructors
• #427 FieldSetter
• #908 FriendlyExceptionMaker
• #431 HandyReturnValues
• #432 InvocationMarker
• #462 InvocationsFinder
• #908 JUnitDetecter
• #490 MissingInvocationChecker
• #490 MissingInvocationInOrderChecker
• #514 MockUtil
• #503 NonGreedyNumberOfInvocationsInOrderChecker
• #907 NumberOfInvocationsInOrderChecker
• #907 NumberOfInvocationsChecker
• #547 ObjectMethodsGuru
• #427 Reporter
• #535 SuperTypesLastSorter
• #501 TestMethodFinder
• #515 VerifiableInvocationsFinder

[ChristianSchwarz]

I would like that all methods invoked in the current class are referenced with this. (and super. for that matter).

To me it feels like unnecessary/duplicate code cause this is implicit. Adding this. before every instance call would create a lot more text and would IMHO reduce readability. E.g.:

this.doSometing(this.withPrivateMethod()) vs. doSomething(withPrivateMethod())

Therefore if we see this.verify, we know it is in the current class and the same object, whereas verify references a static method in this class, or an imported static method.

An other option avoid ambiguity is to qualify static methods via its class name. This way you can also distinguish which verify(…) is called ( MockitoCore.verify(..) / Mocktio.verify(..)) , which is not an easy task when a static import is used.

[ChristianSchwarz]

@TimvdLippe know what you mean! The next PR’s include only one refactored class at a time.