Specify `Locale` when calling `String#to{Lower,Upper}Case`

[Rick Ossendrijver]

Problem

When calling String#to{Lower,Upper}Case without arguments, the system's Locale is used by default.
To prevent this we want our code to specify Locale.ROOT.
Therefore, we want to rewrite occurrences that invoke the aforementioned methods without Locale and introduce Locale.ROOT.

Description of the proposed new feature

• Support a stylistic preference.
• Avoid a common gotcha, or potential problem.

I would like to rewrite the following code:

"A".toLowerCase();
"B".toUpperCase();

to:

"A".toLowerCase(Locale.ROOT);
"B".toUpperCase(Locale.ROOT);

Considerations

Just a consideration; instead of Locale.ROOT one can also use other Locales. I assume we want to leave those as is, right?

Participation

This is a nice opportunity for contributing an Error Prone check 😄.

[Stephan Schroevers]

Just a consideration; instead of Locale.ROOT one can also use other Locales. I assume we want to leave those as is, right?

Certainly!

This is a nice opportunity for contributing a Refaster rule 😄.

I'd rather see this implemented using a BugChecker which suggest the Locale.ROOT fix by default, but proposes Locale.getDefault() as a secondary fix. The latter is (a) behavior preserving, (b) may be more appropriate in certain contexts (such as desktop applications) and (c) might make for an easier migration in large code bases. (I.e.: first do the safe thing by using Locale.getDefault() everywhere, disallow new .to{Lower,Upper}Case() calls, then review and replace such usages if/when possible.

[Rick Ossendrijver]

That makes sense, let's create a BugChecker for this then. I updated the description 👍🏻.

[Luke Prananta]

I'm looking to pick this one up, any pointers before I begin?

[Rick Ossendrijver]

Yes @mlrprananta for sure.

I would say this will be quite similar to the FluxFlatMapUsage, RefasterAnyOfUsage and (a little more complex maybe:) the IdentityConversion checks.

On a first glance, it sounds like the BugChecker needs to implement the MethodInvocationTreeMatcher and use a custom Matcher (see the aforementioned checks for some examples) and match on the methods from this ticket.
Next up, there will be two SuggestedFixes, just as @Stephan202 describes here. The FluxFlatMapUsage also has multiple fixes, so there you can also see how we test that 😄.

Are these pointers helpful? If not, or if you have any questions, feel free to reach out 😉.

[Luke Prananta]

Opened a PR (#376), PTAL 🙂

[Rick Ossendrijver]

Resolved in #376.