Re: GROOVY-12147 and default locales

On 7/12/26 02:45, Paul King wrote:
> Good point Jochen. I am not sure I understood the full picture of
> where you'd like to head,

well, I did not want to give a definitive direction. I wanted to start a=
=20
discussion that then hopefully will result in an understood decision. I=20
am aware that what I was talking about is probably a bit opinionated.

to explain my point of view a bit more. The Laptop I use for development=
=20
has LANG currently set to en_US.UTF-8 ( default Locale would be set=20
accordingly). But frankly the key point for the system here is UTF-8.=20
Not en_US. And a CI may also have a locale like that. I am using the=20
en_US locale mostly because I do not want to have for example=20
"germanization" of menus from my system UI. It is a pain if you have to=20
search for how to configure something in your window manager for=20
example. Also the localization under Linux is often incomplete or has=20
non-idiomatic translations.

At the same time I develop applications for Swiss and German customers.=20
They do not want to see a US locale. They want to see dates and numbers=20
in Swiss or German format, they want to see the user interface (textual=20
or graphical) using maybe English, maybe Swiss-German, Swiss-Italian,=20
Swiss-French, or German. I also had once an application that=20
additionally had to support Spanish. The Spain-Spanish, to be exact. And=
=20
if I have to support currencies, they are usually not singular. For=20
example CHF and EUR at the same time.

> but I tried to capture in a ticket some of
> what you said folded in with the JDK builtin "Best Practices":
>=20
> * Use Locale.ROOT for any data that is meant for machines, protocols,
> file formats, network code, or internal database keys.
> * Use Locale.getDefault() exclusively when you are rendering text,
> dates, numbers, or currencies directly onto a user interface for a
> human to read.
>=20
> But we can debate how we might further tweak those best practices.
>=20
> Jira ticket is here:
> https://issues.apache.org/jira/browse/GROOVY-12152

Locale.ROOT sounds good. But do we really want to add all those Locale=20
variants to the methods in the first place? Plus, is Locale even the=20
right contact point?

then there is the question of "what is machine facing code". If I have=20
to write timestamped values I usually want to write the time in UTC,=20
maybe a shortform of it, and the values in non grouping mode. But there=20
is no Locale for this.

This is form the javadoc of Locale:
"""
[...]
The Java Platform provides a number of classes that perform=20
locale-sensitive operations. For example, the NumberFormat class formats=
=20
numbers, currency, and percentages in a locale-sensitive manner. Classes=
=20
such as NumberFormat have several convenience methods for creating a=20
default object of that type. For example, the NumberFormat class=20
provides these three convenience methods for creating a default=20
NumberFormat object:

          NumberFormat.getInstance()
          NumberFormat.getCurrencyInstance()
          NumberFormat.getPercentInstance()


Each of these methods has two variants; one with an explicit locale and=20
one without; the latter uses the default FORMAT locale:

          NumberFormat.getInstance(myLocale)
          NumberFormat.getCurrencyInstance(myLocale)
          NumberFormat.getPercentInstance(myLocale)


A Locale is the mechanism for identifying the kind of object=20
(NumberFormat) that you would like to get. The locale is just a=20
mechanism for identifying objects, not a container for the objects=20
themselves.
[...]
"""

And the last sentence is the key here. Even if I define a custom Locale=20
for my needs, NumberFormat.getInstance() would not know about it. I am=20
instead forced to have my own NumberFormat instance, that is configured=20
to my needs. And that is what then would have to be used for the=20
formatting of numbers, not the Locale. So maybe those methods should=20
take NumberFormat instead of Locale? Just putting that out here to=20
challenge the current implementation idea.

Just in case someone is interested... The way to make=20
NumberFormat.getInstance(myLocale) pick up my custom format would be to=20
write an SPI provider. And there is no programmatic way for this I would=
=20
know.

bye Jochen