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

[Glavo]

>
> There's a lot more thinking required before considering adding new APIs
> like this. It requires thinking about new developers writing toy programs
> that could easily be confused by two methods that appear to do the same
> thing. Also needs taking a broader view on how it works with other locale
> sensitive APIs.
>

One of the important reasons why I am so eager to have new APIs is to solve
the problems caused by toLowerCase()/toUpperCase() for new developers.

At present, if we want to teach new developers how to convert between
uppercase and lowercase, we have two options:

* Tell them to use toLowerCase()/toUpperCase()

This is a concise choice, but the learners often do not realize the true
meaning of these methods.

As mentioned earlier, these two methods are often misused in most cases.
If we teach like this, learners may write more problematic code in the
future.

* Tell them to use toLowerCase(Locale.ROOT)/toUpperCase(Locale.ROOT)

This is the right choice, but unfortunately, it is very complex.

Its meaning is not as concise and intuitive, and we have to encourage users
to learn about Locale earlier.


The correct writing is lengthy and not intuitive, while problematic writing
is actually shorter.
Short but problematic writing and lengthy but correct writing may cause
confusion for users.

 It requires thinking about new developers writing toy programs that could
> easily be confused by two methods that appear to do the same thing.
>

Due to the above reasons, I think what you said is completely reversed.

What will cause confusion to users is the current situation, and the new
APIs will solve these issues.
The new API will provide a short and correct writing that is intuitive and
can maintain consistency with the semantics of
compareIgnoreCase/equalsIgnoreCase.
For toLowerCase()/toUpperCase(), we just need to tell the user that they
are just legacy issues and never use them.


I understand that Java 21 is around the corner and you have a lot of work
to do, so I'm sorry for taking up so much of your time.
But for this issue, I think it really needs to be corrected. If new APIs
cannot be added in Java 21, it means that correcting these legacy issues in
the community will take at least two more years.
I earnestly request that you pay more attention to this issue, and I am
extremely grateful.

Glavo

On Sun, Apr 16, 2023 at 3:07 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/04/2023 13:39, Glavo wrote:
>
> :
>
> 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
>
>
> There's a lot more thinking required before considering adding new APIs
> like this. It requires thinking about new developers writing toy programs
> that could easily be confused by two methods that appear to do the same
> thing. Also needs taking a broader view on how it works with other locale
> sensitive APIs.
>
> In your list, auditing the usages in the JDK to identify usages where it
> should be using Locale.ROOT instead of Locale.getDefault would be helpful.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230416/b611a671/attachment-0001.htm>