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.ri...@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$>
