new recipe that changes .equals() to .contentEquals() when comparing …

[AlekSimpson]

…a string with a StringBuilder

What's changed?

This PR adds a new recipe that finds when .equals() is being used to compare a string and a StringBuilder, StringBuffer or CharSequence.

What's your motivation?

#22

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

I think the precondition checks should be correct but maybe they could be narrowing things down more.

Anyone you would like to review specifically?

@timtebeek

Checklist

• I've added unit tests to cover both positive and negative cases
• I've added the license header to any new files through ./gradlew licenseFormat
• I've used the IntelliJ auto-formatter on affected files
• I've updated the documentation (if applicable)

[timtebeek]

We can probably also move these to a field above.

[timtebeek]

In terms of tests it would be good to have cases where either the first or the second select is not a string variable or constant, but for instance a method invocation, to be sure we handle those fairly predictable scenarios well.

[timtebeek]

Might want to adjust ./gradle/licenceHeader.txt and this here to set the right year.

[AlekSimpson]

I added that test for if the recipe will run correctly on selects that are a method call.

[timtebeek]

Great work! I've added another polish commit in 18287b2; with changes such as

• Use markdown in getDisplayName() and getDescription() around code elements, for better readability in the docs
• Remove nested if statements in favor of early returns; this helps keep the code readable
• Minimize use of loops through a wildcard matcher on java.lang.* toString() and TypeUtils.isAssignableTo("java.lang.CharSequence", JavaType); we try to avoid Streams for performance reasons (fewer object allocations), and it leads less code as well.
• Minimize public visibility in tests

Hope you don't mind, and I look forward to the next one!