Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

Naoto Sato naoto.sato at oracle.com
Thu Apr 13 16:08:32 UTC 2023


I too agree with Roger that deprecation would have high bar.

Another possibility to mitigate the situation rather than introducing 
the new methods is to introduce a new system property and let the users 
decide the default (yes, yet another property, but I believe it 
warrants). Say,

java.lang.String.defaultCaseLocale=[root/display/format]

where each value designates

root -> Locale.ROOT
display -> Locale.getDefault(Locale.Category.DISPLAY)
format -> Locale.getDefault(Locale.Category.FORMAT)

The choice for the "default" default have room to discuss, but format 
may not be bad choice.

As to the current spec, we can emphasize the Turkish issue more visible 
by making "Notes:" to @apiNote.

Naoto

On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:
>     In that case, isn't there something a little backwards about saying
>     we should continue sweeping them under the rug? (Am I being too
>     idealistic?)
> 
> 
> I sympathise with the concern of causing many warnings/errors, and the 
> right time to do these things never seems to be "now".
> 
> But let's look at it this way: The Turkish population alone is 
> currently 1.08 percent of the world population. If we assume the number 
> of Java apps/services per capita is the same around the world, this 
> means that these methods may return the expected result in 98.92 percent 
> of the executions. I think that's a bit scary.
> 
> Deprecating these methods would require consensus and support from 
> reviewers, which we don't seem to have at the moment. So I think the 
> current focus on fixing the uses inside OpenJDK and then adding 
> alternatives first seems good. Then, maybe someday.. :-)
> 
> Eirik.


More information about the core-libs-dev mailing list