Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

[Glavo]

>
> Sorry Glavo, I cannot support this plan as it appears to be trying to rush
> #1 and #4 into the current release.
>

This is not true, I only hope that the first step - two new API methods -
can become a part of Java 21.

The fourth step must be completed after the first and third steps are
completed, or perhaps never.

 As I said in the other mail, it's very disruptive and requires broader
> consideration and thinking about other locale sensitive APIs.
>

I don't understand why the first step is disruptive. It just adds two new
methods, replacing toLowerCase(ROOT) and toUpperCase(ROOT).

I've detailed the reasons for introducing a new API earlier, and I hope
you'll take a look at it:

https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104118.html


Best regards,
Glavo


On Sat, Apr 15, 2023 at 5:08 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/04/2023 08:50, Glavo wrote:
>
> Hi Alan,
>
> In discussions with others, my thoughts have changed.
>
> I describe the issue in more detail[1] and have a new plan:
>
> 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.
>>
>
> I hope to prioritize the first step now, at least introducing a new clean
> API in Java 21.
> Do you have any opinions on this plan?
>
>
> Sorry Glavo, I cannot support this plan as it appears to be trying to rush
> #1 and #4 into the current release. As I said in the other mail, it's very
> disruptive and requires broader consideration and thinking about other
> locale sensitive APIs.
>
> #3 is the only part of this list that make sense right now.
>
> -Alan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230415/127f6fbe/attachment-0001.htm>