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