Could jmh respect system format settings on Windows or use "C" (simplest one) for machine-related output (CSV)?

[Aleksey Shipilev]

On 09/20/2016 04:07 PM, Lev Serebryakov wrote:
> On 20.09.2016 16:48, Aleksey Shipilev wrote:
>> If your applications use inconsistent locales, then neutral locale does
>> not help: the locales for input app and output app would still be
>> inconsistent. If your applications use consistent locales (e.g. agree on
>  IMHO, all machine-readable formats should use "C" locale. Period. 

Debatable. In my book, machine-readable means "formats that can be
written and read by machines in non-ambiguous manner". CSV is not a
machine-readable format, by this definition. Actually, no format that
does not establish the consensus on encoding its basic types is
machine-readable. This means "choosing the locale" is a weird term for
the actual machine-readable format, because it explicitly says about the
encoding forms, regardless of the regional differences.

> CSV is unlucky exception, where many aspects are implementation-defined, but
> IMHO, software should try to be good citizen and use "C" locale. Again,
> you could not produce XML or PostScript or PDF with "," as delimiter for
> decimal numbers, it will be wrong. CVS is not so strict per RFC, but CVS
> with "." will not violate RFC too.

The next thing you know, you will have the bug report that would
complain that JMH emits CSV numbers without regard for system locale.
Wait, we had these reports already, and this is why it now consults the
system locale!

> All system software works as expected. I configured "." as decimal
> delimiter in my system and it works. It works in native Win32 software,
> it works in QT-based software. Everywhere. But Java.

core-libs-dev@ is a good list to ask about this. Note though, the
radical opinions ("Period."), universal claims without a background
historical research, and ranty emails would have much higher chance to
be ignored on those high-traffic lists.

>   Ok, maybe here is more global question to Java support for locales
> (looks like Java asks system only for "name" and use its own database of
> settings which I could not change), but, again, IMHO, all
> machine-readable formats should be locale-neutral.
> 
>  Here is no "LANG=C java -jar jmh.jar" equivalent on Windows, unfortunately.

IIRC, there are -Duser.country and -Duser.language settings in OpenJDK,
aren't those the same as LANG/LC_ALL?

Thanks,
-Aleksey