On Wed, Apr 12, 2023 at 10:27 PM 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. > It is a matter of fact that case conversion is a locale sensitive operation. By not deprecating these methods, we can pretend it isn't so, but that does not make the problem go away, it just hides it. 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. > In a globalized world, the developer's locale and the user's locale are not necessarily, probably usually, not the same. Case in point, where a developer in Australia is bitten by this, having customers in Turkey: https://mattryall.net/blog/the-infamous-turkish-locale-bug Bug descriptions and blogs like these are plentiful and easy to find. > 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. The current draft PR suggests to deprecate and add @SuppressWarnings("deprecated"), then handle the @SuppressWarnings in follow-up PRs. This could of course be done in the opposite order. > The topics of deprecation and a new API should be treated separately, > they have different costs and benefits. > The draft PR now focuses on deprecation only: https://github.com/openjdk/jdk/pull/13434
