<div dir="ltr">The core problem of these two methods is that they should have clear semantics (locale sensitive), <br>but due to a large number of misuses, they cannot express the user's intention.<br><br>The only point in making their behavior configurable is that for buggy legacy code<br>we can modify the configuration to make it behave correctly. It is not helpful for<br>developers who are writing new code, as developers understand in almost always aware <br>of whether they need locale sensitivity, so using this vague methods actually masks <br>their intentions.<br><br>Our only way to make these methods with huge historical burdens usable is to <br>change and fix their behavior to be locale insensitive. But this is a breaking<br>change and will cause trouble for users who use the new version of JDK but <br>target the old version of JRE.<br><br>In summary, we cannot satisfy users with them, so we can only give them up and<br>let all users no longer use them in new code.<br><br><br>Another issue is that we can use `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`<br>to achieve the expected behavior, so why do we need to introduce a new API?<br><br>For this issue, we need to take a look at the current way.<br><br>Firstly, it is lengthy, so users may feel impatient with it.<br><br>This lengthy way not only lacks clarity, but also reduces readability.<br>It forces the user to use Locale when it is not locale sensitive, which generates <br>noise, and also makes it harder for the user to find which parts of the code are <br>locale sensitive.<br><br>This is why I want to introduce new APIs.<br><br><br>---<br><br>These are the steps I believe are reasonable to address these issues:<br><br>1. Add new locale insensitive APIs and recommend users to use them in new code.<br><br>   I hope this step can be implemented in Java 21.<br><br>2. Add a new system property that allows users to configure the behavior of<br>   these two methods.<br><br>3. Gradually clean up the use cases inside JDK.<br><br>   Since this involves a dozen modules and hundreds of source files, I need to <br>   split them into many PRs, and some of them require CSR. Reviewing them may <br>   take a long time, this step will be done slowly in the future.<br><br>4. Deprecate the two methods.<br>   <br>   This step may take place much later.<br>   <br>This is my idea, and I hope to receive your opinion.<br><br>Glavo<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 14, 2023 at 12:08 AM Naoto Sato <<a href="mailto:naoto.sato@oracle.com" target="_blank">naoto.sato@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I too agree with Roger that deprecation would have high bar.<br>
<br>
Another possibility to mitigate the situation rather than introducing <br>
the new methods is to introduce a new system property and let the users <br>
decide the default (yes, yet another property, but I believe it <br>
warrants). Say,<br>
<br>
java.lang.String.defaultCaseLocale=[root/display/format]<br>
<br>
where each value designates<br>
<br>
root -> Locale.ROOT<br>
display -> Locale.getDefault(Locale.Category.DISPLAY)<br>
format -> Locale.getDefault(Locale.Category.FORMAT)<br>
<br>
The choice for the "default" default have room to discuss, but format <br>
may not be bad choice.<br>
<br>
As to the current spec, we can emphasize the Turkish issue more visible <br>
by making "Notes:" to @apiNote.<br>
<br>
Naoto<br>
<br>
On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:<br>
>     In that case, isn't there something a little backwards about saying<br>
>     we should continue sweeping them under the rug? (Am I being too<br>
>     idealistic?)<br>
> <br>
> <br>
> I sympathise with the concern of causing many warnings/errors, and the <br>
> right time to do these things never seems to be "now".<br>
> <br>
> But let's look at it this way: The Turkish population alone is <br>
> currently 1.08 percent of the world population. If we assume the number <br>
> of Java apps/services per capita is the same around the world, this <br>
> means that these methods may return the expected result in 98.92 percent <br>
> of the executions. I think that's a bit scary.<br>
> <br>
> Deprecating these methods would require consensus and support from <br>
> reviewers, which we don't seem to have at the moment. So I think the <br>
> current focus on fixing the uses inside OpenJDK and then adding <br>
> alternatives first seems good. Then, maybe someday.. :-)<br>
> <br>
> Eirik.<br>
</blockquote></div></div>