<i18n dev> Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

[Xueming Shen]

To have separate sun.stdout.encoding and sun.stderr.encoding is mainly 
because of implementation
convenience. I need three things from the native (1) is std.out tty (2) 
is std.err tty (3) the console
encoding if (1) or (2) are true, and I tried to avoid to go down to 
native multiple times it appears
passing back two encoding name is the easiest approach. The original 
plan was to remove them after
use, maybe via sun.misc.VM.saveAndRemoveProperties() (or simply remove 
them directly), but then
thought the info might be useful...

Auto detect the encoding of InputStreamReader when it is attached the 
console is nice to have, but
I would try to avoid doing that until I have to, before that I would 
still advise the use of java.io.Console
class:-)

-Sherman

>
>>> Why are there theoretically different code pages for stdout and stderr?
>>
>> you can re-direct std err to a log file file but keep the std out to 
>> the console, or re-direct
>> the std out but keep the std.err to the console, in these scenario, 
>> the stderr and stdout
>> will use different code page. Basically the approach is that if the 
>> otuput stream gets
>> re-directed, it keeps using the default charset (with the assumption 
>> that the rest of the
>> world is using the Windows codepage), if not, use the oem codepage 
>> from the console
>> on Windows, to make sure the System.out/err outputs the bits that the 
>> underlying
>> console can understand.
> Oops, I'm not sure, if you didn't misunderstood me.
> I mean, why are there 2 different properties? :
>     "sun.stdout.encoding"
>     "sun.stderr.encoding"
> Shouldn't something be enough like
>     "console.encoding"
> as counterpart to
>      "file.encoding"
> ?
>
> -Ulf
>