ImplicitDefaultLocale rule should not check for deprecated functions

[marschwar]

Expected Behavior of the rule

The ImplicitDefaultLocale rule should not check for usage of toUpperCase and toLowerCase.

Context

The extension functions String.toUpperCase and String.toLowerCase have been deprecated in favor of uppercase and lowercase. Both function by default use the Locale.ROOT and make the check obsolete

[atulgpt]

Hi, @marschwar should this rule be updated to handle uppercase(and similarly lowercase) asking as these new methods already handle locale info correctly by using Locale.ROOT which is not system dependent.

Or is an action item of this issue is to remove this rule?

[marschwar]

TBH I wondered the same thing and hoped this would start a discussion. I am not entirely sure if the problem this rule addresses is still present with Locale.Root or not.

[atulgpt]

if you see the doc of Root locale at https://docs.oracle.com/javase/8/docs/api/java/util/Locale.html#ROOT then you will find below doc(emphasis mine)

Useful constant for the root locale. The root locale is the locale whose language, country, and variant are empty ("") strings. This is regarded as the base locale of all locales, and is used as the language/country neutral locale for the locale sensitive operations.

So to me, it seems that Locale.ROOT basically handles the original issue(my understanding of the original issue is that when using the old methods which use default JVM locale sometimes we end up getting some different capital or small letters based on the locale)

[marschwar]

I agree. We could either close this issue then or remove the toUpperCase and toLowerCase handling from the rule. As it has been deprecated since 1.5 I would opt for removal. What do you think?

[atulgpt]

I agree. We could either close this issue then or remove the toUpperCase and toLowerCase handling from the rule. As it has been deprecated since 1.5 I would opt for removal. What do you think?

I agree as this is now inherently handled by the newer methods. While the older methods are deprecated(and it's also been long since those methods are deprecated)

[marschwar]

I have updated the issue title and description.

[BraisGabin]

Which is the use case? You don't want to get the same issue twice? One by the compiler and the other by detekt?

[marschwar]

It is not about the deprecation warning. This rule currently checks, that those two deprecated methods are used correctly.

How have we handled this in the past? Should we really check if deprecated methods are used correctly?

[BraisGabin]

I don't think we handled this in the past. TL;DR: I agree, we can remove the support for those two functions.

[Gosunet]

Hello, I can propose a PR to do that if you like?

If I understand correctly I just need to delete the check?