> On Jan 26, 2023, at 9:27 PM, Glavo <zjx001...@gmail.com> wrote: > > They only need to use "str".toLowerCase(Locale.ROOT).
Sorry, with a workaround I meant to have toLowerCase() work without modifying the existing source code to use toLowerCase(Locale.ROOT). Xuelei > > On Fri, Jan 27, 2023 at 1:18 PM Xuelei Fan <xuele...@gmail.com > <mailto:xuele...@gmail.com>> wrote: >> Just curious, this is a known issue for many years, how those areas like >> Turkish survive? Is there a workaround for those areas or the use of the >> methods is not common any longer? >> >> Xuelei >> >>> On Jan 26, 2023, at 4:35 AM, Glavo <zjx001...@gmail.com >>> <mailto:zjx001...@gmail.com>> wrote: >>> >>> At present, the no-parameter toLowerCase and toUpperCase methods of String >>> are based on the default locale. >>> >>> I checked all the uses of this method in OpenJDK, and found that most of >>> the use cases are suspicious, and even there are some hidden bugs. >>> For example, I just found that jdk.incubator.vector.LaneType will trigger >>> assertion failure on Turkish locale, and opened a PR for this problem: >>> >>> https://github.com/openjdk/panama-vector/pull/210 >>> >>> In addition to such obvious problems, some use cases behave suspiciously >>> after calling Locale.setDefault. >>> I am investigating these problems and preparing to open a PR to solve these >>> hidden bugs. >>> >>> In all the third-party libraries I have used, I have never seen the correct >>> use of these two methods. >>> Although the behavior of modifying API methods is destructive, I think it >>> is worthwhile to consider whether to modify its behavior for such a >>> suspicious method. >>> If users need locale-sensitive case conversion, it may be better to >>> explicitly use Locale.getDefault(). >>> Using Locale.ROOT as the default value also helps to keep the behavior of >>> these two methods consistent with equalsIgnoreCase, >>> Character.toLowerCase/toUpperCase and other methods. >>> >>> This is my rough idea. I hope to get your suggestions. >>
