> 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 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. > 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? Glavo On Thu, Apr 13, 2023 at 10:13 PM Roger Riggs <roger.ri...@oracle.com> wrote: > 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$> >> >> >
