[Proposal] Make toLowerCase and toUpperCase based on Locale.ROOT by default
Glavo
zjx001202 at gmail.com
Thu Jan 26 14:42:45 UTC 2023
The reason why I want to modify their behavior is that a large number of
programs have misused this method.
By modifying the behavior, we can fix them without modifying their source
code.
However, it may be a better choice to mark it as deprecated.
After deprecating them, we can provide new API methods that use
Locale.ROOT by default as a substitute.
Kotlin is using methods called lowercase() and uppercase() for this
purpose, which I think can be used for reference.
On Thu, Jan 26, 2023 at 9:36 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>
> ------------------------------
>
> *From: *"Glavo" <zjx001202 at gmail.com>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> *Sent: *Thursday, January 26, 2023 1:35:06 PM
> *Subject: *[Proposal] Make toLowerCase and toUpperCase based on
> Locale.ROOT by default
>
> 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.
>
>
> yes, it's a very very common bug, IntelliJ already warns when
> toLowerCase()/toUpperCase() is used without a Locale.
> I think the logical nest step is more to deprecate
> toLowerCase()/toUpperCase() than to change their implementation.
>
> regards,
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230126/61041005/attachment.htm>
More information about the core-libs-dev
mailing list