<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>I think this can only be used as a transitional solution, and it doesn't really<br>solve the problem - the semantics of toLowerCase()/toUpperCase() are still vague,<br>so toLowerCase(Locale)/toUpperCase(Locale) is still needed to get deterministic <br>behavior.<br><br>I agree that this solution can be used instead of deprecating these two APIs,<br>but I think the new APIs are still necessary. <br></div><div><br></div><div>Glavo</div></div><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">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>