On 4/16/23 8:47 AM, Glavo wrote:
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
>
> 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
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
>
> 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
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
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
On 13/04/2023 15:58, Glavo wrote:
:
I thought it might be more efficient to discuss after creating a draft PR.
It seems that it is difficult to attract more experts to participate
in the
discussion only on the mailing list. Do you have any suggestions for this?
This proposal is not
The core problem of these two methods is that they should have clear
semantics (locale sensitive),
but due to a large number of misuses, they cannot express the user's
intention.
The only point in making their behavior configurable is that for buggy
legacy code
we can modify the configuration to
>
> Another possibility to mitigate the situation rather than introducing
> the new methods is to introduce a new system property and let the users
> decide the default (yes, yet another property, but I believe it
> warrants). Say,
>
I think this can only be used as a transitional solution, and
I too agree with Roger that deprecation would have high bar.
Another possibility to mitigate the situation rather than introducing
the new methods is to introduce a new system property and let the users
decide the default (yes, yet another property, but I believe it
warrants). Say,
>
> In that case, isn't there something a little backwards about saying we
> should continue sweeping them under the rug? (Am I being too idealistic?)
>
I sympathise with the concern of causing many warnings/errors, and the
right time to do these things never seems to be "now".
But let's look at
On Thu, Apr 13, 2023 at 9:14 AM Roger Riggs wrote:
> 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.
>
Hmm.. I'd agree with this statement if
> In my experience, it will take longer to agree on the deprecation than
adding a simple API with known semantics.
All right, so I'll focus on creating new APIs first. I hope to get it at
least in Java 21.
It is also acceptable to deprecate the old API at a later date.
As observed, coming to
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
>
> 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
On Wed, Apr 12, 2023 at 10:27 PM Roger Riggs 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.
>
It is a
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
Von: core-libs-dev im Auftrag von Archie Cobbs Gesendet: Mittwoch, April 12, 2023 12:33 AMAn: Glavo Cc: Remi Forax ; core-libs-dev Betreff: Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative On Tue, Apr 11, 2023 at 4:52 PM Glavo <zjx001...@gmail.
On Tue, Apr 11, 2023 at 4:52 PM Glavo wrote:
> i'm not sure that the methods lowercase() and uppercase() are a good
>> addition.
>> Their names are too close to toLowerCase/toUpperCase thus too easy to
>> misuse ones for the others.
>>
>
> I'm fine with users having to write
lot of noise, so we also need to eliminate it
Glavo
On Wed, Apr 12, 2023 at 4:21 AM Remi Forax wrote:
>
>
> --
>
> *From: *"Glavo"
> *To: *"core-libs-dev"
> *Sent: *Tuesday, April 11, 2023 10:02:01 PM
> *Subje
:
>
>
> --
>
> *From: *"Glavo"
> *To: *"core-libs-dev"
> *Sent: *Tuesday, April 11, 2023 10:02:01 PM
> *Subject: *Draft: Deprecate toLowerCase()/toUpperCase() and provide
> locale insensitive alternative
>
> Hi everyone,
>
> From: "Glavo"
> To: "core-libs-dev"
> Sent: Tuesday, April 11, 2023 10:02:01 PM
> Subject: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale
> insensitive alternative
> Hi everyone,
> A few months ago, I discussed in this mailing li
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.
23 matches
Mail list logo
