hashCode and toString should not be called on array instances. RSPEC-2116

[yeikel]

While hashCode and toString are available on arrays, they are largely useless. hashCode returns the array’s "identity hash code", and toString returns nearly the same value. Neither method’s output actually reflects the array’s contents. Instead, you should pass the array to the relevant static Arrays method.

    String argStr = args.toString(); // Noncompliant
    int argHash = args.hashCode(); // Noncompliant

    String argStr = Arrays.toString(args);
    int argHash = Arrays.hashCode(args);

More examples with Strings

int[] s = new int[]{1,2,3};
System.out.println(s);
Sytem.out.println(String.format("s=%s",s));

// .. any other usage where a String is expected

int[] s = new int[]{1,2,3};
System.out.println(Arrays.toString(s));
Sytem.out.println(String.format("s=%s",Arrays.toString(s)));

// .. any other usage where a String is expected

https://rules.sonarsource.com/java/RSPEC-2116

[tkvangorder]

This could be generalized with a recipe called "ChangeMethodInvocation" that matches a given method pattern and changes the invocation to an alternate method invocation that has a possibly different "select" and accepts the same arguments.

[mccartney]

ChangeMethodInvocation [...] accepts the same arguments.

Except in this case the arguments are different (as opposed to #43)

[timtebeek]

Some implementation notes:

• both methods are available on all objects, so any implementation is performance sensitive: limit & return early where possible
• probably best to implement hashCode separate from toString, as that's slightly easier
• toString() can also be implied for arguments headed into String.format; that's probably best handled in a separate recipe or visitor to check the arguments to String.format() and similar methods such as printf.

[timtebeek]

Reopened until we also merge in the separate recipes for toString #126