System properties

[Michael Hall]

On May 26, 2012, at 9:34 AM, Andrew Thompson wrote:

> Honestly, I think we probably are at a point where this change makes sense. More than a decade has passed. But at the very least it should *never* *ever* be US ASCII in any shipping build (which would be going backwards from MacRoman) and it really *should* be in the release notes, because this is not a small change, though it is a subtle one. Its fair to make an explicit choice to do this, its not a good idea to do it by accident.

Not sure why you're cross-posting back to java-dev. Hasn't been MRJ for a while has it?

Fwiw, I downloaded the Oracle JDK . This property, file.encoding, remains the same, that is set as US-ASCII.
Somewhat interestingly maybe, if I do a locale in Terminal I get…
locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
…for a bunch of other LC_

If I do it from my application….
exec locale
LANG=
LC_COLLATE="C"
…and again a bunch of other LC_ set the same.
I think it was said earlier that if you were using the C/POSIX locale then the US-ASCII setting is right? 

The following I think confirms that I"m picking up the Oracle JRE. The openjdk build, Is that what your build is Henri?,  that build has been set os.arch=universal
set os.arch
os.arch=x86_64