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

[Roger Riggs]

Hi,

In my experience, it will take longer to agree on the deprecation than 
adding a simple API with known semantics.

An important element of the deprecation messaging is the potential 
replacement.
Having the replacement in hand gives a clear message and action that can 
be scripted.
IDE's would also be able to suggest and apply.

And yes, it is a problem to cause many warnings; it creates an immediate 
and pressing need for projects that have tight source requirements and 
don't allow warnings, for example, the JDK itself.

An expectation-wise, the June 8 Rampdown Phase One is closer than it 
appears.
There are significant number of projects that are queuing up to beat the 
deadline, but compete for resources to review.

Regards, Roger


On 4/13/23 3:34 AM, Glavo wrote:
>
>     Deprecating the existing methods would cause lots of warnings and
>     provide little actual improvement.
>
>
> I don't think there is only little actual improvement.
>
> **Almost all** use cases of these two methods are misuse. Even the 
> correct use
> of them is not recommended, as there are too many misuses, making it 
> difficult
> to distinguish between correct use and misuse. Replacing them with
> toLowerCase(Locale.getDefault()) can express intentions more clearly.
> So is it a problem to cause many warnings? I think it's obviously not.
>
> Even these misuses happen to work in most locales, not dealing with 
> them is just
> burying the head in the sand.
>
>     The topics of deprecation and a new API should be treated separately,
>     they have different costs and benefits.
>
>
> This PR is now only deprecating the old method.
>
> I plan to perform a set of tasks in parallel:
>
> * Create a series of PRs to replace their use cases module by module with
>   toLowerCase(Locale)/toUpperCase(Locale);
> * Determine the naming of the new methods and then create a PR to 
> implement it;
> * Deprecate the old methods.
>
> If no one has any objections to this, I would like to start them 
> immediately as
> I hope to complete them before Java 21.
>
> After the above work is completed, I can gradually replace 
> `toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`
> with the new API. This work is not urgent and can be carried out at 
> any time.
>
> Glavo
>
> On Thu, Apr 13, 2023 at 4:27 AM Roger Riggs <roger.riggs at oracle.com> 
> wrote:
>
>     Hi,
>
>     The status quo takes a balance between trying do the right thing and
>     creating a headache for lots of developers.
>     Deprecating the existing methods would cause lots of warnings and
>     provide little actual improvement.
>     Except in a few locales, the output would be the same as today.
>     If you're working in a locale where it matters, it has become
>     habit to
>     use Locale.root everywhere.
>
>     The most positive suggestion from the January thread [1] was to
>     fix the
>     uses in the JDK in small batches and carefully review each to make
>     sure
>     there are no unintended consequences. Even replacing the existing
>     uses
>     with a new method requires the same cautious approach.  Adding new
>     methods was also mentioned.
>
>     The topics of deprecation and a new API should be treated separately,
>     they have different costs and benefits.
>
>     As observed, coming to agreement on the naming is likely the hard
>     part.
>     You might want to start a discussion about that; but it may be too
>     soon
>     for a PR.
>
>     Regards, Roger
>
>
>
>     On 4/11/23 4:02 PM, Glavo wrote:
>     > Hi everyone,
>     >
>     > A few months ago, I discussed in this mailing list[1] whether
>     > toLowerCase()/toUpperCase() should be deprecated.
>     > At that time, I received some approval and no one opposed the
>     > idea. Therefore, I thought it might be time
>     > to continue advancing this work, so I created a PR[2] for this.
>     >
>     > This PR is still a draft, welcome to discuss it there.
>     >
>     > I don't have much experience in contributing to OpenJDK yet, so
>     I also
>     > hope to get the help of experienced
>     > contributors (such as creating CSR). Thanks!
>     >
>     > Glavo
>     >
>     > [1]
>     >
>     https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html
>     > [2] https://github.com/openjdk/jdk/pull/13434
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13434__;!!ACWV5N9M2RV99hQ!PgzNhsfRigH2Aep5P5810AJ-DSVnZjjOvHTWJac-KQ_TT7fySzsLYqVMqNFai_YcDTi0mAz9JgMHyp2JxxI$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230413/fb0c5499/attachment-0001.htm>