> > 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, >
I think this can only be used as a transitional solution, and it doesn't really solve the problem - the semantics of toLowerCase()/toUpperCase() are still vague, so toLowerCase(Locale)/toUpperCase(Locale) is still needed to get deterministic behavior. I agree that this solution can be used instead of deprecating these two APIs, but I think the new APIs are still necessary. Glavo On Fri, Apr 14, 2023 at 12:08 AM Naoto Sato <naoto.s...@oracle.com> wrote: > 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. >
