<div dir="ltr">>
In my experience, it will take longer to agree on the deprecation than adding a simple API with known semantics.<div><br></div><div>All right, so I'll focus on creating new APIs first. I hope to get it at least in Java 21.<br></div><div>It is also acceptable to deprecate the old API at a later date.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As observed, coming to agreement on the naming is likely the hard part.<br>You might want to start a discussion about that; but it may be too soon<br>for a PR.<br></blockquote><div><br></div><div>I thought it might be more efficient to discuss after creating a draft PR.<br>It seems that it is difficult to attract more experts to participate in the<br>discussion only on the mailing list. Do you have any suggestions for this?<br></div><div><br></div><div>Glavo</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 13, 2023 at 10:13 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com">roger.riggs@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Hi,<br>
<br>
In my experience, it will take longer to agree on the deprecation
than adding a simple API with known semantics.<br>
<br>
An important element of the deprecation messaging is the potential
replacement.<br>
Having the replacement in hand gives a clear message and action that
can be scripted.<br>
IDE's would also be able to suggest and apply.<br>
<br>
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.<br>
<br>
An expectation-wise, the June 8 Rampdown Phase One is closer than it
appears. <br>
There are significant number of projects that are queuing up to beat
the deadline, but compete for resources to review.<br>
<br>
Regards, Roger<br>
<br>
<br>
<div>On 4/13/23 3:34 AM, Glavo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Deprecating
the existing methods would cause lots of warnings and<br>
provide little actual improvement.<br>
</blockquote>
<div><br>
</div>
<div>I don't think there is only little actual improvement.<br>
<br>
**Almost all** use cases of these two methods are misuse. Even
the correct use <br>
of them is not recommended, as there are too many misuses,
making it difficult <br>
to distinguish between correct use and misuse. Replacing them
with <br>
toLowerCase(Locale.getDefault()) can express intentions more
clearly.<br>
So is it a problem to cause many warnings? I think it's
obviously not.<br>
<br>
Even these misuses happen to work in most locales, not dealing
with them is just <br>
burying the head in the sand.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The
topics of deprecation and a new API should be treated
separately,<br>
they have different costs and benefits.<br>
</blockquote>
<div><br>
</div>
<div>This PR is now only deprecating the old method.<br>
<br>
I plan to perform a set of tasks in parallel:<br>
<br>
* Create a series of PRs to replace their use cases module by
module with <br>
toLowerCase(Locale)/toUpperCase(Locale);<br>
* Determine the naming of the new methods and then create a PR
to implement it;<br>
* Deprecate the old methods.<br>
<br>
If no one has any objections to this, I would like to start
them immediately as<br>
I hope to complete them before Java 21.<br>
<br>
After the above work is completed, I can gradually replace
`toLowerCase(Locale.ROOT)`/`toUpperCase(Locale.ROOT)`<br>
with the new API. This work is not urgent and can be carried
out at any time.<br>
</div>
<div><br>
</div>
<div>Glavo</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 13, 2023 at
4:27 AM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank">roger.riggs@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
The status quo takes a balance between trying do the right
thing and <br>
creating a headache for lots of developers.<br>
Deprecating the existing methods would cause lots of warnings
and <br>
provide little actual improvement.<br>
Except in a few locales, the output would be the same as
today.<br>
If you're working in a locale where it matters, it has become
habit to <br>
use Locale.root everywhere.<br>
<br>
The most positive suggestion from the January thread [1] was
to fix the <br>
uses in the JDK in small batches and carefully review each to
make sure <br>
there are no unintended consequences. Even replacing the
existing uses <br>
with a new method requires the same cautious approach. Adding
new <br>
methods was also mentioned.<br>
<br>
The topics of deprecation and a new API should be treated
separately, <br>
they have different costs and benefits.<br>
<br>
As observed, coming to agreement on the naming is likely the
hard part.<br>
You might want to start a discussion about that; but it may be
too soon <br>
for a PR.<br>
<br>
Regards, Roger<br>
<br>
<br>
<br>
On 4/11/23 4:02 PM, Glavo wrote:<br>
> Hi everyone,<br>
><br>
> A few months ago, I discussed in this mailing list[1]
whether <br>
> toLowerCase()/toUpperCase() should be deprecated.<br>
> At that time, I received some approval and no one opposed
the <br>
> idea. Therefore, I thought it might be time<br>
> to continue advancing this work, so I created a PR[2] for
this.<br>
><br>
> This PR is still a draft, welcome to discuss it there.<br>
><br>
> I don't have much experience in contributing to OpenJDK
yet, so I also <br>
> hope to get the help of experienced<br>
> contributors (such as creating CSR). Thanks!<br>
><br>
> Glavo<br>
><br>
> [1] <br>
> <a href="https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/099375.html</a><br>
> [2] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13434__;!!ACWV5N9M2RV99hQ!PgzNhsfRigH2Aep5P5810AJ-DSVnZjjOvHTWJac-KQ_TT7fySzsLYqVMqNFai_YcDTi0mAz9JgMHyp2JxxI$" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/13434</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>