The core problem of these two methods is that they should have clear semantics (locale sensitive), but due to a large number of misuses, they cannot express the user's intention.
The only point in making their behavior configurable is that for buggy legacy code we can modify the configuration to make it behave correctly. It is not helpful for developers who are writing new code, as developers understand in almost always aware of whether they need locale sensitivity, so using this vague methods actually masks their intentions. Our only way to make these methods with huge historical burdens usable is to change and fix their behavior to be locale insensitive. But this is a breaking change and will cause trouble for users who use the new version of JDK but target the old version of JRE. In summary, we cannot satisfy users with them, so we can only give them up and let all users no longer use them in new code. Another issue is that we can use `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)` to achieve the expected behavior, so why do we need to introduce a new API? For this issue, we need to take a look at the current way. Firstly, it is lengthy, so users may feel impatient with it. This lengthy way not only lacks clarity, but also reduces readability. It forces the user to use Locale when it is not locale sensitive, which generates noise, and also makes it harder for the user to find which parts of the code are locale sensitive. This is why I want to introduce new APIs. --- These are the steps I believe are reasonable to address these issues: 1. Add new locale insensitive APIs and recommend users to use them in new code. I hope this step can be implemented in Java 21. 2. Add a new system property that allows users to configure the behavior of these two methods. 3. Gradually clean up the use cases inside JDK. Since this involves a dozen modules and hundreds of source files, I need to split them into many PRs, and some of them require CSR. Reviewing them may take a long time, this step will be done slowly in the future. 4. Deprecate the two methods. This step may take place much later. This is my idea, and I hope to receive your opinion. 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. >
