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,
java.lang.String.defaultCaseLocale=[root/display/format]
where each value designates
root -> Locale.ROOT
display -> Locale.getDefault(Locale.Category.DISPLAY)
format -> Locale.getDefault(Locale.Category.FORMAT)
The choice for the "default" default have room to discuss, but format
may not be bad choice.
As to the current spec, we can emphasize the Turkish issue more visible
by making "Notes:" to @apiNote.
Naoto
On 4/13/23 8:39 AM, Eirik Bjørsnøs wrote:
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 it this way: The Turkish population alone is
currently 1.08 percent of the world population. If we assume the number
of Java apps/services per capita is the same around the world, this
means that these methods may return the expected result in 98.92 percent
of the executions. I think that's a bit scary.
Deprecating these methods would require consensus and support from
reviewers, which we don't seem to have at the moment. So I think the
current focus on fixing the uses inside OpenJDK and then adding
alternatives first seems good. Then, maybe someday.. :-)
Eirik.
