<div dir="ltr"><div dir="ltr">On Wed, Apr 12, 2023 at 10:27 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com">roger.riggs@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><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></blockquote><div><br></div><div>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. </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">
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></blockquote><div><br></div><div>In a globalized world, the developer's locale and the user's locale are not necessarily, probably usually, not the same. </div><div><br></div><div>Case in point, where a developer in Australia is bitten by this, having customers in Turkey:</div><div><br></div><div><a href="https://mattryall.net/blog/the-infamous-turkish-locale-bug">https://mattryall.net/blog/the-infamous-turkish-locale-bug</a><br></div><div><br></div><div>Bug descriptions and blogs like these are plentiful and easy to find.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.</blockquote><div><br></div><div>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.</div><div> </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>The draft PR now focuses on deprecation only:</div><div> </div><div><a href="https://github.com/openjdk/jdk/pull/13434" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/13434</a></div></div></div>