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

[Lev Serebryakov]

On 20.09.2016 18:03, Aleksey Shipilev wrote:

> 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!
 To be honest, it doesn't, as my example shows ;-) It consult some
non-obvious custom locale, not system one. But I understand, that JMH
could do little (nothing) in this area, after it is chosen to use locale
at all.


 Maybe, it is good idea to add one more *machine-readable* format (see
JMH's help for "-rff" and "-rf" options, which uses this wording) like
"cvs-ln"? I can prepare patch for it :-) It will solve all problems,
IMHO. Here is "scsv" already for compatibility purposes.

>> 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.
  Sorry for my language, I was not right here. I could only say, that I
is very tired with all this locale/region-related problems and
interoperability breaks due to this stupid comma in default Russian
locale. And, yes, I've seen software, which emits PostScript with "," as
decimal delimiter if it is chosen in current locale.

-- 
// Black Lion AKA Lev Serebryakov