Replaced usage of String.to[U/L]Case() with String.equalsIgnoreCase()

[tbw777]

No needed to convert case to compare strings in different case. The better in memory and cpu way is to use equalsIgnoreCase() method.

JMH tests showing that String.equalsIgnoreCase() method faster then String.to[U/L]Case().equals() about several times.

[neilcsmith-net]

These don't necessarily have the same behaviour, as switching from something that is Locale dependent to something that isn't?! Which might not be a bad thing, and is hopefully not actually relevant anywhere.

[tbw777]

I think here is no user input or data input from external sources

[neilcsmith-net]

I think here is no user input or data input from external sources

?? What is this in reference to?

[tbw777]

What the potencial source of different locales?

[neilcsmith-net]

to[U/L]Case() are Locale sensitive, equalsIgnoreCase() is not - check Javadoc notes for the 3. Not having behaviour that is potentially different dependent on the Locale settings of the end user is probably a good thing anyway. But this PR is a shift (fix) in behaviour as well as a possible performance improvement.

[mbien]

I looked through this and I believe this should be fine @neilcsmith-net. A lot of this are language identifier comparisons, file endings, SQL queries etc. Whenever there is a comparison with a constant like "dev" it shouldn't matter if the cases are compared with a specific local or not.

The only area I am not 100% sure about is the bugzilla package - maybe you could take a look at this one. If you aren't sure either we can skip it.

[neilcsmith-net]

I looked through this and I believe this should be fine @neilcsmith-net. A lot of this are language identifier comparisons, file endings, SQL queries etc.

I think it looks fine too, although I haven't had time to look at all areas (like bugzilla) yet.

To be more explicit about what I was saying above, I think this should be evaluated as a bug fix. I'm more interested in that aspect of it than any minor performance improvements. And we should probably look for other uses of to[U/L]Case() that are not part of this but questionable, and should be using Locale.ROOT / Locale.ENGLISH.

Whenever there is a comparison with a constant like "dev" it shouldn't matter if the cases are compared with a specific local or not.

That depends on what is being compared, and where the input string is from. Consider -

String input = "LIB";
boolean result = "lib".equals(input.toLowerCase());

The result might be true or false depending on whether you're Turkish or not!

[mbien]

lets get this in